Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-security-topics-05.txt

[Brian Campbell]

That works for me

On Wed, Mar 21, 2018 at 7:34 PM, Torsten Lodderstedt <
tors...@lodderstedt.net> wrote:

> Hi all,
>
> thanks for your feedback. Here is my text proposal for section 3.8.1.
>
> ——
>
> Attackers could try to utilize a user's trust in the authorization
>server (and its URL in particular) for performing phishing attacks.
>
> RFC 6749 already prevents open redirects by stating the AS
> MUST NOT automatically redirect the user agent in case
> of an invalid combination of client_id and redirect_uri.
>
> However, as described in [I-D.ietf-oauth-closing-redirectors], an
> attacker could also utilize a correctly registered redirect URI to
> perform phishing attacks. It could for example register a client
> via dynamic client registration and intentionally send an
> erroneous authorization request, e.g. by using an invalid
> scope value, to cause the AS to automatically redirect the user
> agent to its phishing site.
>
> The AS MUST take precautions to prevent this threat.
> Based on its risk assessment the AS needs to decide whether
> it can trust the redirect URI or not and should only automatically
> redirect the user agent, if it trusts the redirect URI. If not, it could
> inform the user that it is about to redirect her to the another site
> and rely on the user to decide or just inform the user about the
> error.
>
> ——
>
> kind regards,
> Torsten.
>
>
>

-- 
*CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
material for the sole use of the intended recipient(s). Any review, use, 
distribution or disclosure by others is strictly prohibited.  If you have 
received this communication in error, please notify the sender immediately 
by e-mail and delete the message and any file attachments from your 
computer. Thank you.*
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] Comments on draft-ietf-oauth-security-topics-05

[Phil Hunt]

Torsten,

Great document!

Some minor nits and comments:

Abstract - double period after first sentence.

> It updates and extends the OAuth 2.0 Security Threat Model to
>incorporate practical experiences gathered since OAuth 2.0 was
>published and cover new threats relevant due to the broader
>application of OAuth 2.0.

When I first read, it sounds like this is a replacement for the threat model or 
at least could be read that way. I think you mean readers still need to read 
6819. How about...

"This specification uses the OAuth 2.0 Security Threat Model and supplements it 
to incorporate practical experiences gathered"...

Section 1.

The paragraph starting “OAuth initially assumed a static…” appears to continue 
the previous bullet point.  Should the paragraph be indented?

Last paragraph 3.1.1
> This kind of injections is covered in
>Section Code Injection.

Should this say Section 3.5?

Section 3.1.5
This paragraph seems unfinished...
> 
>  Question: Does redirect uri validation solve any problem for
>   native apps?  Effective against impersonation when used in
>   conjunction with claimed HTTPS redirect URIs only.
>   For Windows token broker exact redirect URI matching is important
>   as the redirect URI encodes the app identity.  For custom scheme
>   redirects there is a question however it is probably a useful part
>   of defense in depth.

Section 3.4
> AS returns client_id and its iss in the response.  Client compares
>   this data to AS it believed it sent the user agent to.
“client_id” and “iss” attributes do not appear to have any marking () in multiple locations in the document.

Section 3.5
> How does an attack look like?
How about:
"An attack looks like:”

Writing style of the following comment seems like an editors note rather than a 
comment for the reader.  Rephrase?

>But this approach conflicts with the idea to enforce exact redirect
>URI matching at the authorization endpoint.  Moreover, it has been
>observed that providers very often ignore the redirect_uri check
>requirement at this stage, maybe, because it doesn't seem to be
>security-critical from reading the spec.

Is this appropriate for a BCP (seems like a WG discussion item)?
>The authors therefore propose to the working group to drop this
>feature in favor of more effective and (hopefully) simpler approaches
>to code injection prevention as described in the following section.

Section 3.5.1

This seems a bit tentatively worded…
>PKCE seem to be the most obvious solution for OAuth clients as it
>available and effectively used today for similar purposes for OAuth
>native apps whereas "nonce" is appropriate for OpenId Connect
>clients.

Formatting problem (missing line between paragraphs)?
>Note on pre-warmed secrets: An attacker can circumvent the
>countermeasures described above if he is able to create or capture
>the respective secret or code_challenge on a device under his
>control, which is then used in the victim's authorization request.
>Exact redirect URI matching of authorization requests can prevent the
>attacker from using the pre-warmed secret in the faked authorization
>transaction on the victim's device.
>Unfortunately it does not work for all kinds of OAuth clients.  It is
>effective for web and JS apps and for native apps with claimed URLs.
>Attacks on native apps using custom schemes or redirect URIs on
>localhost cannot be prevented this way, except if the AS enforces
>one-time use for PKCE verifier or Nonce values.


Phil

Oracle Corporation, Identity Cloud Services Architect
@independentid
www.independentid.com phil.h...@oracle.com 

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

Re: [OAUTH-WG] JSON Web Token Best Current Practices draft describing Explicit Typing

[Mike Jones]

I propose that the following text be added to address your comment, Brian.  
Does this text work for you?

When applying explicit typing to a Nested JWT, the "typ" header parameter 
containing the explicit type value MUST be present in the inner JWT of the 
Nested JWT (the JWT whose payload is the JWT Claims Set).  The same "typ" 
header parameter value MAY be present in the outer JWT as well, to explicitly 
type the entire Nested JWT.

   -- Mike

From: Brian Campbell 
Sent: Monday, July 17, 2017 10:53 AM
To: Phil Hunt (IDM) 
Cc: Mike Jones ; oauth@ietf.org
Subject: Re: [OAUTH-WG] JSON Web Token Best Current Practices draft describing 
Explicit Typing

Could some more guidance be provided around how to use the explicit typing with 
nested JWTs?
I'd imagine that the "typ" header should be in the header of the JWT that is 
integrity protected by the issuer?

On Tue, Jul 4, 2017 at 9:58 PM, Phil Hunt (IDM) 
mailto:phil.h...@oracle.com>> wrote:
+1

Thanks Mike.

Phil

On Jul 4, 2017, at 12:43 PM, Mike Jones 
mailto:michael.jo...@microsoft.com>> wrote:
The JWT BCP draft has been updated to describe the use of explicit typing of 
JWTs as one of the ways to prevent confusion among different kinds of JWTs.  
This is accomplished by including an explicit type for the JWT in the “typ” 
header parameter.  For instance, the Security Event Token (SET) 
specification now uses the 
“application/secevent+jwt” content type to explicitly type SETs.

The specification is available at:

  *   https://tools.ietf.org/html/draft-sheffer-oauth-jwt-bcp-01

An HTML-formatted version is also available at:

  *   http://self-issued.info/docs/draft-sheffer-oauth-jwt-bcp-01.html

   -- Mike

P.S.  This notice was also posted at http://self-issued.info/?p=1714 and as 
@selfissued.
___
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


CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
material for the sole use of the intended recipient(s). Any review, use, 
distribution or disclosure by others is strictly prohibited.  If you have 
received this communication in error, please notify the sender immediately by 
e-mail and delete the message and any file attachments from your computer. 
Thank you.
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-security-topics-05.txt

[Justin Richer]

I like the new text, it frames the error better and puts it in the context 
where it’s likely to be exploited. IE, newly dynamically registered clients 
shouldn’t be trusted as much as others.

 — Justin

> On Mar 22, 2018, at 8:16 AM, Brian Campbell  
> wrote:
> 
> That works for me
> 
> On Wed, Mar 21, 2018 at 7:34 PM, Torsten Lodderstedt  > wrote:
> Hi all,
> 
> thanks for your feedback. Here is my text proposal for section 3.8.1.
> 
> ——
> 
> Attackers could try to utilize a user's trust in the authorization
>server (and its URL in particular) for performing phishing attacks.
> 
> RFC 6749 already prevents open redirects by stating the AS
> MUST NOT automatically redirect the user agent in case
> of an invalid combination of client_id and redirect_uri.
> 
> However, as described in [I-D.ietf-oauth-closing-redirectors], an
> attacker could also utilize a correctly registered redirect URI to
> perform phishing attacks. It could for example register a client
> via dynamic client registration and intentionally send an
> erroneous authorization request, e.g. by using an invalid
> scope value, to cause the AS to automatically redirect the user
> agent to its phishing site.
> 
> The AS MUST take precautions to prevent this threat.
> Based on its risk assessment the AS needs to decide whether
> it can trust the redirect URI or not and should only automatically
> redirect the user agent, if it trusts the redirect URI. If not, it could
> inform the user that it is about to redirect her to the another site
> and rely on the user to decide or just inform the user about the
> error.
> 
> ——
> 
> kind regards,
> Torsten.
> 
> 
> 
> 
> CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
> material for the sole use of the intended recipient(s). Any review, use, 
> distribution or disclosure by others is strictly prohibited..  If you have 
> received this communication in error, please notify the sender immediately by 
> e-mail and delete the message and any file attachments from your computer. 
> Thank you.___
> 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] JSON Web Token Best Current Practices draft describing Explicit Typing

[Brian Campbell]

Yeah, I think that works. Thanks.

On Thu, Mar 22, 2018 at 2:16 PM, Mike Jones 
wrote:

> I propose that the following text be added to address your comment,
> Brian.  Does this text work for you?
>
>
>
> When applying explicit typing to a Nested JWT, the "typ" header parameter
> containing the explicit type value MUST be present in the inner JWT of the
> Nested JWT (the JWT whose payload is the JWT Claims Set).  The same "typ"
> header parameter value MAY be present in the outer JWT as well, to
> explicitly type the entire Nested JWT.
>
>
>
>-- Mike
>
>
>
> *From:* Brian Campbell 
> *Sent:* Monday, July 17, 2017 10:53 AM
> *To:* Phil Hunt (IDM) 
> *Cc:* Mike Jones ; oauth@ietf.org
> *Subject:* Re: [OAUTH-WG] JSON Web Token Best Current Practices draft
> describing Explicit Typing
>
>
>
> Could some more guidance be provided around how to use the explicit typing
> with nested JWTs?
>
> I'd imagine that the "typ" header should be in the header of the JWT that
> is integrity protected by the issuer?
>
>
>
> On Tue, Jul 4, 2017 at 9:58 PM, Phil Hunt (IDM) 
> wrote:
>
> +1
>
>
>
> Thanks Mike.
>
> Phil
>
>
> On Jul 4, 2017, at 12:43 PM, Mike Jones 
> wrote:
>
> The JWT BCP draft has been updated to describe the use of explicit typing
> of JWTs as one of the ways to prevent confusion among different kinds of
> JWTs.  This is accomplished by including an explicit type for the JWT in
> the “typ” header parameter.  For instance, the Security Event Token (SET)
> specification  now uses the “
> application/secevent+jwt” content type to explicitly type SETs.
>
>
>
> The specification is available at:
>
>- https://tools.ietf.org/html/draft-sheffer-oauth-jwt-bcp-01
>
>
>
> An HTML-formatted version is also available at:
>
>- http://self-issued.info/docs/draft-sheffer-oauth-jwt-bcp-01.html
>
>
>
>-- Mike
>
>
>
> P.S.  This notice was also posted at http://self-issued.info/?p=1714 and
> as @selfissued .
>
> ___
> 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
>
>
>
>
> *CONFIDENTIALITY NOTICE: This email may contain confidential and
> privileged material for the sole use of the intended recipient(s). Any
> review, use, distribution or disclosure by others is strictly prohibited.
> If you have received this communication in error, please notify the sender
> immediately by e-mail and delete the message and any file attachments from
> your computer. Thank you.*
>

-- 
*CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
material for the sole use of the intended recipient(s). Any review, use, 
distribution or disclosure by others is strictly prohibited.  If you have 
received this communication in error, please notify the sender immediately 
by e-mail and delete the message and any file attachments from your 
computer. Thank you.*
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] OAuth 2.0 Seamless Flow - first draft

[Omer Levi Hevroni]

Hey
After presenting the flow yesterday, I've submitted the first draft:
https://tools.ietf.org/html/draft-seamless-flow-00
I tried to answer all the question that raised during the session.
Looking forward to hear your feedback.
Omer
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] I-D Action: draft-ietf-oauth-jwt-bcp-01.txt

[internet-drafts]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Web Authorization Protocol WG of the IETF.

Title   : JSON Web Token Best Current Practices
Authors : Yaron Sheffer
  Dick Hardt
  Michael B. Jones
Filename: draft-ietf-oauth-jwt-bcp-01.txt
Pages   : 12
Date: 2018-03-22

Abstract:
   JSON Web Tokens, also known as JWTs [RFC7519], are URL-safe JSON-
   based security tokens that contain a set of claims that can be signed
   and/or encrypted.  JWTs are being widely used and deployed as a
   simple security token format in numerous protocols and applications,
   both in the area of digital identity, and in other application areas.
   The goal of this Best Current Practices document is to provide
   actionable guidance leading to secure implementation and deployment
   of JWTs.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-oauth-jwt-bcp/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-oauth-jwt-bcp-01
https://datatracker.ietf.org/doc/html/draft-ietf-oauth-jwt-bcp-01

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-jwt-bcp-01


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.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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