[Unbearable] New Special Publication 800-63-3 "Digital Identity Guidelines" Suite published

[Denis <[e-mail]>]

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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/saag
>
>
>
>
> _______________________________________________
> saag mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/saag