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

From: [email-masked]
Date: Tue, 14 Nov 2017 03:49:00 -0800

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           : OAuth Security Topics
        Authors         : Torsten Lodderstedt
                          John Bradley
                          Andrey Labunets
	Filename        : draft-ietf-oauth-security-topics-04.txt
	Pages           : 26
	Date            : 2017-11-14

Abstract:
   This draft gives a comprehensive overview on open OAuth security
   topics.  It is intended to serve as a working document for the OAuth
   working group to systematically capture and discuss these security
   topics and respective mitigations and eventually recommend best
   current practice and also OAuth extensions needed to cope with the
   respective security threats.

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

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-oauth-security-topics-04
https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics-04

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-security-topics-04

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/

---

From: Torsten Lodderstedt <[email-masked]>
Date: Tue, 14 Nov 2017 21:28:03 +0800

Hi all,

I just published revision -04. 

Changes:
Added best practices on Token Leakage prevention
Restructured document for better readability

kind regards,
Torsten. 

> Anfang der weitergeleiteten Nachricht:
> 
> Von: [email-masked]
> Betreff: [OAUTH-WG] I-D Action: draft-ietf-oauth-security-topics-04.txt
> Datum: 14. November 2017 um 19:49:00 GMT+8
> An: <[email-masked]>
> Kopie: [email-masked]
> 
> 
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: Nat Sakimura <[email-masked]>
Date: Tue, 14 Nov 2017 16:44:34 +0000

Thanks, Torsten.

In 4.11, you can probably add client_secret and code phishing explained in
https://nat.sakimura.org/2016/01/22/code-phishing-attack-on-oauth-2-0-rfc6749/
.
I do not like the mitigation strategy there at all, though. Now that we
have MTLS draft, using that is much better.

The current document is based on the known threat analysis. As Andrey
pointed out in the Trier seminar, most problems actually arise from the
failure of 1) Source authentication, 2) Destination authentication, and 3)
Message authentication. This, I think, is a good viewpoint.
The [BCM] paper further recommends to have 4) protocol version and message
identifier,  5) full list of actor/roles in addition. It will probably make
the protocol provably secure as well.

Perhaps we can add these as a consideration to mitigating unknown attacks.
Also, analysing each known attacks in light of 1) to 5) above will provide
a uniform viewpoint to each attack, so it may be worthwhile to do.

Nat

[BCM] Basin, D., Cremers, C., Meier, S.: Provably Repairing the ISO/IEC 9798
Standard for Entity Authentication. Journal of Computer Security - Security
and Trust Principles archive Volume 21 Issue 6, 817-846 (2013)

On Tue, Nov 14, 2017 at 10:28 PM Torsten Lodderstedt <
[email-masked]> wrote:

>    - Added best practices on Token Leakage prevention
>
>
>    - Restructured document for better readability
>
>
> kind regards,
> Torsten.
>
> *Von: [email-masked]
> *Betreff: **[OAUTH-WG] I-D Action:
> draft-ietf-oauth-security-topics-04.txt*
> *Datum: *14. November 2017 um 19:49:00 GMT+8
> *An: *<[email-masked]>
> *Kopie: [email-masked]
>
>
>
-- 

Nat Sakimura

Chairman of the Board, OpenID Foundation

---

From: Denis <[email-masked]>
Date: Wed, 15 Nov 2017 12:53:11 +0100

Comments on draft-ietf-oauth-security-topics-04

1. Section 2.2 states:

    2.2.  Token Leakage Prevention
        Authorization servers _*shall*_ use TLS-based methods for sender
        constraint access tokens as described in section Section 4.7.1.2,
        such as token binding [I-D.ietf-oauth-token-binding] or Mutual TLS
        for OAuth 2.0 [I-D.ietf-oauth-mtls].  It is also recommend to use
        end-to-end TLS whenever possible.

Since this draft is intended to be a Best Current Practice (BCP) 
document , "shall" should be replaced by "should".

2. Collusion between clients is not addressed but should be mentioned. 
It is proposed to add a section
that would placed before section 4.7 (Access Token Leakage at the 
Resource Server) that would have the following content:

    Access Token Leakage at the client

    It’s been a while since the OAuth WG has published in RFC 6819
    [RFC6819]. At this time, the threat model was considering
    various types of attacks performed by attackers or by Resource
    Servers but did not take into consideration collusion between clients.

    A client could legitimately obtain an access token and then could
    attempt to allow its use by another client. If the access token
    contains
    a sufficient number of attributes that allows to unambiguously
    identify the client, it is unlikely that the legitimate client will
    transmit it
    to another client since that other client would be able to
    impersonate the legitimate client. However, if it is not the case
    (e.g. the access token
    contains a single attribute like "over 18"), the legitimate owner of
    the access token may be willing to collaborate with another client
    because
    the collusion will not be seen by the Authorization server nor the
    Resource Server.

    While protecting private keys in secure elements or in TPMs is
    certainly necessary, it is insufficient since the legitimate owner
    of the access token
    would be able to perform all the cryptographic computations that the
    other client needs.

    The counter-measures described in section 4.7.1.2 (Sender
    Constrained Access Tokens) are unable to counter collusion between
    clients.

3. A section about privacy considerations is missing. It is proposed to 
add a section 8 with the following content:

    8. Privacy considerations

    Techniques able to solve security concerns are not necessarily able
    to solve privacy concerns. The counter-measures described in section
    4.7.1.3
    (Audience Restricted Access Tokens) allow authorization servers to
    know where each token they issue will be used. This may be a privacy
    concern
    for some clients. Current techniques do not address a way to prevent
    authorization servers to know where the tokens they issue will be used.
    This leaves room to extend OAuth in order to add privacy properties.

Denis