Subject: [saag] Security Controls for Interception proxies outbound connections?

From: Jeffrey Walton <[email-masked]>
Date: Tue, 21 Mar 2017 12:30:30 -0400

Hi Everyone,

US Cert recently released TA17-075A, "HTTPS Interception Weakens TLS
Security", https://www.us-cert.gov/ncas/alerts/TA17-075A. It seems to
be a restatement of Jarmoc's "SSL Interception Proxies and Transitive
Trust", https://media.blackhat.com/bh-eu-12/Jarmoc/bh-eu-12-Jarmoc-SSL_TLS_Interception-Slides.pdf.

What security controls are available to contain the threats related to
the proxy's outbound connection? Does the IETF offer anything?

Jeff

---

From: Denis <[email-masked]>
Date: Sat, 25 Mar 2017 16:39:06 +0100

I would like to draw your attention, on the fact that the work performed 
both by the OAuth WG and the Token Binding WG is currently
unable to counter a major threat scenario that has been described in an 
earlier e-mail sent to the OAuth WG as the "ABC attack" or
the "Alice and Bob Collusion attack".

See: https://www.ietf.org/mail-archive/web/oauth/current/msg16767.html

This threat is not mentioned in RFC 6819 : OAuth 2.0 Threat Model and 
Security Considerations (2013).
Hence, nobody attempted to find a solution ... for a threat that had not 
been identified.

A basic property of the current Token Binding mechanisms being developed 
by the Token Binding WG is that a specific piece of software
voluntarily installed by a client can export any token and perform all 
the needed computations so that any token can successfully be used
by another client. It is _NOT the replay of a token_, since the token is 
not used at any time by the legitimate owner, but is used by an illegitimate
user. As the above link mentions:

    Whatever kind of cryptographic is being used, when two users
    collaborate, a software-only solution
    will be unable to prevent the transfer of an attribute of a user
    that possess it to another user that does not possess it .

    The use of a secure element simply protecting the confidentiality
    and the integrity of some secret key or private key
    will be ineffective to counter the Alice and Bob collusion attack.
    Additional properties will be required for the secure element.

Hence, any method able to counter the ABC attack requires the *use of 
secure elements* by the users.

The objectives of the Token Binding WG are as follows:

The main design objectives for the Token Binding protocol, in no 
particular order:

1. Allow applications and services to prevent unauthorized replay of 
security tokens. (...)

At the present this objective has not been met and will never be met 
until some secure element will be used by clients.

The HTTP binding mechanism being developed by the Token Binding WG gets 
more and more complex ...
but will be insecure (i. e 'broken') as soon as someone will develop a 
piece of software able to by-pass it.

Many people believe that it is "impossible" to counter this 
threat/attack and thus, since it is "impossible", a mechanism unable
to address this issue is equal in terms of security to another mechanism 
unable to solve this issue (!).

Another key point is that none of the techniques mentioned hereafter is 
able to counter the ABC attack, i.e. the transmission
and then the use of an access token legitimately obtained by a user to 
another user, as soon as they agree to cooperate :

·    U-Prove from Microsoft,
·    Identity Mixer (Idemix) from IBM,
·    the IRMA Project (which is a combination of the *use of a smart 
card *and of Idemix), and
·    OpenID Connect.

This means in particular that these methods are unable to support an 
ABAC (Attribute Based Access Control) model.

Denis

DP Security Consulting SAS. France.

---

From: Benjamin Kaduk <[email-masked]>
Date: Sat, 25 Mar 2017 22:57:59 -0500

Hi Denis,

> unable to counter a major threat scenario that has been described in an 

With all due respect, I do not believe that there is consensus to
apply the modifier "major" to this threat scenario.

> See: https://www.ietf.org/mail-archive/web/oauth/current/msg16767.html

While it may be the case that the authors and participants of these
working groups are interested in desiging protocols that allow
non-malicious clients to gain protection for themselves from
malicious third parties even though the actual text of the charter
permits designing protections against malicious clients, it seems
that the proper response may be to reevaluate the charter text and
the desired goals from the work and the working group, rather than
to insist that this attack be considered and addressed.  That is to
say, though there are threat models in which the ABC attack is a
"real" attack, those are not necessarily the threat models in which
people are interested in working, and I do not think there is much
support for attempting to force one threat model on other WG
participants absent explicit consensus to adopt such a threat model
for the scope of some work.

-Ben

---

From: Denis <[email-masked]>
Date: Mon, 27 Mar 2017 10:16:51 +0200

Hi Ben,

> apply the modifier "major" to this threat scenario.

This depends of the content of the access token.

If the access token contains a sufficient number of attributes able to 
fully identify one individual in a given context,
Bob will disagree to collaborate with Alice because Alice would then be 
able to impersonate as Bob.

On the contrary, if the access token *does not contain *a sufficient 
number of attributes able to fully identify one individual
in a given context, Bob cannot be identified as being the one who got 
the access token that has been transmitted to Alice
and thus Bob is very likely to accept to collaborate with Alice based on 
the property: "*not seen, not taken*".

This is why I said : "This means in particular that these methods 
[U-Prove, Idemix, the IRMA Project, OpenID Connect and OAuth 2.0]
are unable to support an ABAC (*Attribute Based Access Control*) model".

    Atttribute-based authentication aims to provide a mechanism for
    precisely doing this: allowing transactions on the basis of those
    attributes
    which are required for the transaction. (...) The attribute that is
    most needed now is probably the minimal-age attribute, like ‘over 18’.

    Extract from "Credential Design in Attribute-Based Identity
    Management" available at:
    https://www.cs.ru.nl/~gergely/objects/TILTing_Alpar-Jacobs_CredentialDesign.pdf

If a person over 18 can transmit an access token to anybody under 18 and 
if this person is then able to use that token,
without the server being able to detect that this is a collusion attack, 
then I consider that this is a *major *problem.

This is not only a *major *problem for *OAuth 2.0*, but also a *major 
*problem for both *U-Prove* and *Idemix*, and as a consequence
for the now-closed *ABC4Trust* project.

> to insist that this attack be considered and addressed.

If you have a technique able to counter the ABC attack, then it will 
also protect users from malicious third parties,
while the reverse is not true.

> That is to say, though there are threat models in which the ABC attack is a

OAuth 2.0 is currently not restricting access tokens to only contain a 
sufficient set of attributes that allows to fully identify
an individual in a given context.

Since OAuth 2.0 allows access tokens to contain non-directly 
identifiable attributes, this is indeed a *major *problem.

Denis

======================================================================================================================
Original message:

Denis

---

From: Yoav Nir <[email-masked]>
Date: Mon, 27 Mar 2017 13:29:47 -0500

Hi, Denis

> On 27 Mar 2017, at 3:16, Denis <[email-masked]> wrote:
> 
> Hi Ben,
> 
>> Hi Denis,
>> 

I don’t think the question is whether this is major or minor. The question is whether this is without our threat model or not.

> If the access token contains a sufficient number of attributes able to fully identify one individual in a given context,
> Bob will disagree to collaborate with Alice because Alice would then be able to impersonate as Bob.

This implies that Bob has a very complex trust policy for Alice. I don’t think this reflects the real world. “Here, Alice, take my driver’s license. Please don’t drink too much” is far more realistic.

> On the contrary, if the access token does not contain a sufficient number of attributes able to fully identify one individual
> in a given context, Bob cannot be identified as being the one who got the access token that has been transmitted to Alice
> and thus Bob is very likely to accept to collaborate with Alice based on the property: "not seen, not taken”.

Regardless of the psychology of Bob, this goes against the data minimization recommendation from RFC 6973. One of the attractive properties of OAuth is that Bob does not need to send name, address, fingerprint and SSN to the resource server in order to buy (for example) vodka.  All he needs to do is send a token proving he’s over 18. There is a balance to be struck between the need to prevent Bob from misusing his ability to get a token and the need to limit information shared with the resource server.

If anything, the part of the process that needs to be fixed is not that the access token is used by (not Bob), but that Bob was able to obtain a token for (not Bob). Not that I have a good solution for that. But absent technical solutions that are also workable, it is enough to say that the Authorization Server has a trust relationship with Bob, and trusts Bob to not obtain tokens on behalf of others. Same as the DMV trusts him not to give his driver’s license to his niece.

> This is why I said : "This means in particular that these methods [U-Prove, Idemix, the IRMA Project, OpenID Connect and OAuth 2.0]
> are unable to support an ABAC (Attribute Based Access Control) model".
> Atttribute-based authentication aims to provide a mechanism for precisely doing this: allowing transactions on the basis of those attributes
> which are required for the transaction. (...) The attribute that is most needed now is probably the minimal-age attribute, like ‘over 18’.
> 
> Extract from "Credential Design in Attribute-Based Identity Management" available at:
> https://www.cs.ru.nl/~gergely/objects/TILTing_Alpar-Jacobs_CredentialDesign.pdf <https://www.cs.ru.nl/~gergely/objects/TILTing_Alpar-Jacobs_CredentialDesign.pdf>
> If a person over 18 can transmit an access token to anybody under 18 and if this person is then able to use that token,
> without the server being able to detect that this is a collusion attack, then I consider that this is a major problem.

You know, Bob can just buy the vodka himself and give it to her.

> This is not only a major problem for OAuth 2.0, but also a major problem for both U-Prove and Idemix, and as a consequence
> for the now-closed ABC4Trust project.
> 
>> 
>>> See: https://www.ietf.org/mail-archive/web/oauth/current/msg16767.html <https://www.ietf.org/mail-archive/web/oauth/current/msg16767.html>
> If you have a technique able to counter the ABC attack, then it will also protect users from malicious third parties,
> OAuth 2.0 is currently not restricting access tokens to only contain a sufficient set of attributes that allows to fully identify
To me, this is a feature.
> Since OAuth 2.0 allows access tokens to contain non-directly identifiable attributes, this is indeed a major problem.
> 
> Denis

---

From: Denis <[email-masked]>
Date: Mon, 27 Mar 2017 21:03:31 +0200

Hi Yoav,

My responses are embedded in the text, with "Denis:" in front of my 
responses.

> Hi, Denis
>
>> On 27 Mar 2017, at 3:16, Denis <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>>
>> Hi Ben,
>>
>>> Hi Denis,
>>>
> I don’t think the question is whether this is major or minor. The 
> question is whether this is without our threat model or not.

Denis : The threat was *not placed **voluntarily **outside of the threat 
model*. It is currently outside the threat model because
no one thought about it. Now the threat has been identified. We can't 
ignore it anymore.

>
>> If the access token contains a sufficient number of attributes able 
>> to fully identify one individual in a given context,
> This implies that Bob has a very complex trust policy for Alice. I 
> don’t think this reflects the real world. “Here, Alice, take my 
> driver’s license. Please don’t drink too much” is far more realistic.

Denis: One the contrary, this is a very simple psychology. If Bob "can 
be seen and taken", he won't accept,
but if Bob "cannot be seen and cannot be taken", there is no danger 
anymore and he may accept.

>
>> On the contrary, if the access token*does not contain*a sufficient 
>> and thus Bob is very likely to accept to collaborate with Alice based 
>> on the property: "*not seen, not taken*”.
>
> Regardless of the psychology of Bob, this goes against the data 
> minimization recommendation from RFC 6973.

Denis: No it doesn't.

> One of the attractive properties of OAuth is that Bob does not need to 
> send name, address, fingerprint and SSN to the resource server in 
> order to buy (for example) vodka.
> All he needs to do is send a token proving he’s over 18. There is a 
> balance to be struck between the need to prevent Bob from misusing his 
> ability to get a token and
> the need to limit information shared with the resource server.

Denis: We agree that "All he needs to do is send a token proving he’s 
over 18".

> If anything, the part of the process that needs to be fixed is not 
> that the access token is used by (not Bob),
> but that Bob was able to obtain a token for (not Bob). Not that I have 
> a good solution for that.

Denis :  It seems that we agree that needs to be fixed 'one way or the 
other'.

> But absent technical solutions that are also workable, it is enough to 
> say that the Authorization Server has a trust relationship with Bob,
> and trusts Bob to not obtain tokens on behalf of others. Same as the 
> DMV trusts him not to give his driver’s license to his niece.

Denis: Not exactly: Bob obtains the token for himself, but the current 
Token Binding mechanisms are insufficient to prevent him to forward the 
token
to Alice so that she can successfully use it. The Authorization Server 
will not know that Alice indeed used the token - instead of Bob.

>>     which are required for the transaction. (...) The attribute that
>>     is most needed now is probably the minimal-age attribute, like
>>     ‘over 18’.
>>
>> If a person over 18 can transmit an access token to anybody under 18 
>> and if this person is then able to use that token,
>> without the server being able to detect that this is a collusion 
>> attack, then I consider that this is a*major*problem.
>

Denis: Yes indeed, but the situation is worse. Since Alice has been able 
to get once an access token proving that she is over 18, she is then able
to get any number of bottles every week without any need to bother Bob 
again and again: the server will remember that she is over 18
and hence it will not ask her to prove it again at every access. If she 
is over 18 today, obviously she will still be over 18 tomorrow.

Denis

>
>> This is not only a*major*problem for*OAuth 2.0*, but also 
>> a*major*problem for both*U-Prove*and*Idemix*, and as a consequence
>> for the now-closed*ABC4Trust*project.
>>
>>>
>>>> See:https://www.ietf.org/mail-archive/web/oauth/current/msg16767.html
>> OAuth 2.0 is currently not restricting access tokens to only contain 
>> a sufficient set of attributes that allows to fully identify
>> Since OAuth 2.0 allows access tokens to containnon-directly 
>> identifiable attributes, this is indeed a*major*problem.
>>
>> Denis
>

---

From: Kathleen Moriarty <[email-masked]>
Date: Mon, 27 Mar 2017 15:21:45 -0400

Hi Denis,

One comment inline.

On Mon, Mar 27, 2017 at 3:03 PM, Denis <[email-masked]> wrote:
> I don’t think the question is whether this is major or minor. The question
> is whether this is without our threat model or not.
>
>
> Denis : The threat was not placed voluntarily outside of the threat model.
> It is currently outside the threat model because
> no one thought about it. Now the threat has been identified. We can't ignore
> it anymore.
>
>
>
> If the access token contains a sufficient number of attributes able to fully
> identify one individual in a given context,
> This implies that Bob has a very complex trust policy for Alice. I don’t
> think this reflects the real world. “Here, Alice, take my driver’s license.
> Please don’t drink too much” is far more realistic.
>
>
> Denis: One the contrary, this is a very simple psychology. If Bob "can be
> seen and taken", he won't accept,
> but if Bob "cannot be seen and cannot be taken", there is no danger anymore
> and he may accept.
>
>
> On the contrary, if the access token does not contain a sufficient number of
> attributes able to fully identify one individual
> in a given context, Bob cannot be identified as being the one who got the
> access token that has been transmitted to Alice
> Regardless of the psychology of Bob, this goes against the data minimization
> recommendation from RFC 6973.
>
>
> Denis: No it doesn't.

How do you come to this conclusion?  Am I missing something from your
explanation?  I had the same reaction as Yoav when reading this
thread.  In line with RFC6973, we try to minimize identifying
information to reduce the chance of tracking and assist in increasing
user privacy.

Thanks,
Kathleen
>
> One of the attractive properties of OAuth is that Bob does not need to send
> name, address, fingerprint and SSN to the resource server in order to buy
> (for example) vodka.
> All he needs to do is send a token proving he’s over 18. There is a balance
> to be struck between the need to prevent Bob from misusing his ability to
> get a token and
> Denis: We agree that "All he needs to do is send a token proving he’s over
> 18".
>
>
> If anything, the part of the process that needs to be fixed is not that the
> access token is used by (not Bob),
> but that Bob was able to obtain a token for (not Bob). Not that I have a
> good solution for that.
>
>
> But absent technical solutions that are also workable, it is enough to say
> that the Authorization Server has a trust relationship with Bob,
> and trusts Bob to not obtain tokens on behalf of others. Same as the DMV
> trusts him not to give his driver’s license to his niece.
>
>
> Denis: Not exactly: Bob obtains the token for himself, but the current Token
> Binding mechanisms are insufficient to prevent him to forward the token
> to Alice so that she can successfully use it. The Authorization Server will
> not know that Alice indeed used the token - instead of Bob.
>
>
> This is why I said : "This means in particular that these methods [U-Prove,
> Idemix, the IRMA Project, OpenID Connect and OAuth 2.0]
> Atttribute-based authentication aims to provide a mechanism for precisely
> doing this: allowing transactions on the basis of those attributes
> which are required for the transaction. (...) The attribute that is most
> needed now is probably the minimal-age attribute, like ‘over 18’.
>
> If a person over 18 can transmit an access token to anybody under 18 and if
> this person is then able to use that token,
> then I consider that this is a major problem.
>
>
> Denis: Yes indeed, but the situation is worse. Since Alice has been able to
> get once an access token proving that she is over 18, she is then able
> to get any number of bottles every week without any need to bother Bob again
> and again: the server will remember that she is over 18
> and hence it will not ask her to prove it again at every access. If she is
> over 18 today, obviously she will still be over 18 tomorrow.
>
> Denis
>
>
>
> This is not only a major problem for OAuth 2.0, but also a major problem for
> both U-Prove and Idemix, and as a consequence
> If you have a technique able to counter the ABC attack, then it will also
> protect users from malicious third parties,
> Since OAuth 2.0 allows access tokens to contain non-directly identifiable
> attributes, this is indeed a major problem.
>
> Denis
>
>
>
>
> _______________________________________________
> saag mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/saag
>

-- 

Best regards,
Kathleen

---

From: Yoav Nir <[email-masked]>
Date: Mon, 27 Mar 2017 14:23:45 -0500

> On 27 Mar 2017, at 14:03, Denis <[email-masked]> wrote:
> 
> Hi Yoav,
> 
> My responses are embedded in the text, with "Denis:" in front of my responses.
> 
>> Hi, Denis
>> 
>>> On 27 Mar 2017, at 3:16, Denis <[email-masked] <mailto:[email-masked]>> wrote:
>>> 
>>> Hi Ben,
>>> 
>>>> Hi Denis,
>>>> 
> Denis : The threat was not placed voluntarily outside of the threat model. It is currently outside the threat model because
> no one thought about it. Now the threat has been identified. We can't ignore it anymore.

!ignore != MUST solve

> Denis: One the contrary, this is a very simple psychology. If Bob "can be seen and taken", he won't accept,
> but if Bob "cannot be seen and cannot be taken", there is no danger anymore and he may accept.

And yet people give their driver’s licenses and credit cards to others all the time.

>> Regardless of the psychology of Bob, this goes against the data minimization recommendation from RFC 6973.
> 
> Denis: No it doesn't.
> 
>> One of the attractive properties of OAuth is that Bob does not need to send name, address, fingerprint and SSN to the resource server in order to buy (for example) vodka.
>> All he needs to do is send a token proving he’s over 18. There is a balance to be struck between the need to prevent Bob from misusing his ability to get a token and
> Denis: We agree that "All he needs to do is send a token proving he’s over 18”.

Except that you are advocating “a sufficient number of attributes able to fully identify one individual” in the access token.

>> If anything, the part of the process that needs to be fixed is not that the access token is used by (not Bob),
>> but that Bob was able to obtain a token for (not Bob). Not that I have a good solution for that.
> 
> Denis :  It seems that we agree that needs to be fixed 'one way or the other'.
> 
>> But absent technical solutions that are also workable, it is enough to say that the Authorization Server has a trust relationship with Bob,
>> and trusts Bob to not obtain tokens on behalf of others. Same as the DMV trusts him not to give his driver’s license to his niece.
> 
> Denis: Not exactly: Bob obtains the token for himself, but the current Token Binding mechanisms are insufficient to prevent him to forward the token
> to Alice so that she can successfully use it. The Authorization Server will not know that Alice indeed used the token - instead of Bob.

Somebody’s going to accuse me of semantic hair-splitting, but here goes.  Alice opened account “bieberfan2001” at vodkaRus.com <http://vodkarus.com/>.  vodkaRus requests an authorization token proving that the person behind bieberfan2001 is over 18, so vodkaRus creates a token request, which Alice forwards to Bob, who forwards it to the authorization server, dmv.org <http://dmv.org/> . Bob didn’t get a token for himself - he got a token for an account he has no access to. He got the token for bieberfan2001 by falsely representing to dmv.org <http://dmv.org/> that he was the real person behind bieberfan2001.

>>> https://www.cs.ru.nl/~gergely/objects/TILTing_Alpar-Jacobs_CredentialDesign.pdf <https://www.cs.ru.nl/%7Egergely/objects/TILTing_Alpar-Jacobs_CredentialDesign.pdf>
> Denis: Yes indeed, but the situation is worse. Since Alice has been able to get once an access token proving that she is over 18, she is then able
> to get any number of bottles every week without any need to bother Bob again and again: the server will remember that she is over 18
> and hence it will not ask her to prove it again at every access. If she is over 18 today, obviously she will still be over 18 tomorrow.

And the big question is: do we care?  Does dmv.org <http://dmv.org/> care?

Yoav

---

From: Denis <[email-masked]>
Date: Mon, 27 Mar 2017 21:58:25 +0200

Hi Kathleen,

I am advocating that the token contains an attribute 'over 18' but no 
other attribute(s) that would allow to uniquely identify Bob.

For example, it might also contain (if needed) another attribute like 
"my home address is in North Carolina".
This is along data minimization which is one of the principles of 
privacy by design.

So I meant that if the access token does NOT contain a sufficient number 
of attributes able to uniquely identify Bob
then Bob is very likely to accept to collaborate with Alice based on the 
property: "not seen, not taken”.

Denis