I also read section 8 (Security) from NIST Special Publication 800-63C
(Digital Identity Guidelines).
See: https://pages.nist.gov/800-63-3/sp800-63c.html
Section 8.1 states:*
*
*"*For the purpose of these types of threats, any authorized parties
who attempt to exceed their privileges
are considered attackers".
Section 9.3 identifies a specific use case:
"In some instances, an RP does not require a full value of an
attribute. For example, an RP may need to know
whether the subscriber is over 13 years old, but has no need for
the full date of birth".
However, Bob who is over 13 might attempt to forward an assertion that
he legitimately obtained from an IdP to Alice
who is less than 13. This is a collusion attack that has been named :
the ABC attack (Alice and Bob Collusion attack).
The first description of this attack is available at:
https://www.ietf.org/mail-archive/web/oauth/current/msg16767.html
Such a threat or attack is not identified in this NIST document and
hence no mitigation mechanism is being proposed.
Access token binding protection methods developed either by the Token
Binding WG or by the OAuth WG do not allow
to counter the ABC attack. Either the legitimate user (e.g. Bob) can
provide his key to another user (e.g. Alice), or
if it can't (e.g. because it is protected by a secure element) he sends
requests to his secure element to perform
the cryptographic computations that the other user (e.g. Alice) needs.
The RP will be unable to know which piece of software
or hardware has performed the cryptographic computations.
There are two ways to counter this threat:
-either to include into the assertion a set of attributes that
allows to uniquely identify the user (e.g. name, first name and
other attributes)
but which is against both data minimization privacy principles and
unlinkability privacy principles,
-or to use secure elements that allow to only include an attribute
like "over 13" into the assertion and which are able to defeat the
ABC attack.
On July 13, at the OAuth Security Workshop 2017that will take place
in Zürich, I will present two methods using secure elements while
preserving the user's privacy that are able to defeat the ABC
attack. The title of this presentation is :
" A privacy by design eID scheme supporting Attribute-based Access
Control (ABAC)".
See: https://zisc.ethz.ch/oauth-security-workshop-2017/
Denis
PS. This email is also posted to the OAuth WG mailing list and the the
Token Binding mailing list. Sorry for duplications.
Thank you for providing the links. I read in particular section 5.2
(Privacy Requirements) from
NIST Special Publication 800-63C (Digital Identity Guidelines) which
is reproduced below :
(See: https://pages.nist.gov/800-63-3/sp800-63c.html)
5.2 Privacy Requirements
Federation involves the transfer of personal attributes from a third
party that is not otherwise involved
in a transaction — the IdP. Federation also potentially gives the IdP
broad visibility into subscriber activities.
Accordingly, there are specific privacy requirements associated with
federation.
Communication between the RP and the IdP could reveal to the IdP where
the subscriber is conducting a transaction.
Communication with multiple RPs allows the IdP to build a profile of
subscriber transactions that would not have existed
without federation. This aggregation could enable new opportunities
for subscriber tracking and use of profile information
that do not always align with subscribers’ privacy interests.
The IdP SHALL NOT disclose information on subscriber activities at an
RP to any party, nor use the subscriber’s information
for any purpose other than federated authentication, related fraud
mitigation, to comply with law or legal process, or in the case of a
specific user request, to transmit the information.
The IdP SHOULDemploy technical measures, such as the use of pairwise
pseudonymous identifiers described in Section 6.3
<https://pages.nist.gov/800-63-3/sp800-63c.html#ppi>
or privacy-enhancing cryptographic protocols, to provide unlinkability
and discourage subscriber activity tracking and profiling. (...)
From the point of view of human users, this requirement ("SHALL NOT")
and this recommendation ("SHOULD") are not satisfactory,
since IdPs would be in a position to *act as Big Brother*.
The right requirement should be:
The IdP SHALL NOT be able to know where the subscribers are conducting
transactions.
This has major implications on other parts of these documents.
Denis
Of possible interest...
[congrats to Jim Fenton and Paul Grassi]
<https://pages.nist.gov/800-63-3/>
SP 800-63-3 Digital Identity Guidelines
SP 800-63A Enrollment and Identity Proofing
SP 800-63B Authentication and Lifecycle Management
SP 800-63C Federation and Assertions
On 6/22/17, 7:33 AM, "National Institute of Standards and Technology
(NIST)" wrote:
Mic Drop — Announcing the New Special Publication 800-63 Suite!
06/22/2017 10:02 AM EDT
<http://trustedidentities.blogs.govdelivery.com/2017/06/22/mic-drop-announcing-the-new-special-publication-800-63-suite/>
More than a year in the making, after a large, cross-industry effort,
we are proud to announce that the new Special Publication (SP) 800-63
IS. NOW. FINAL. With your help, Electronic Authentication Guidelines
has evolved into Digital Identity Guidelines—a suite of documents
covering digital identity from initial risk assessment to deployment
of federated identity solutions. Check it out now at
<https://pages.nist.gov/800-63>!
_______________________________________________
saag mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/saag
_______________________________________________
saag mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/saag
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
