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

Denis <denis.ietf@free.fr> Fri, 23 June 2017 10:51 UTC

Return-Path: <denis.ietf@free.fr>
X-Original-To: unbearable@ietfa.amsl.com
Delivered-To: unbearable@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 5DDD5128B88; Fri, 23 Jun 2017 03:51:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.597
X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id D6eE0OywHBTZ; Fri, 23 Jun 2017 03:51:11 -0700 (PDT)
Received: from smtp6-g21.free.fr (smtp6-g21.free.fr [IPv6:2a01:e0c:1:1599::15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E5F2B1200ED; Fri, 23 Jun 2017 03:51:10 -0700 (PDT)
Received: from [] (unknown []) by smtp6-g21.free.fr (Postfix) with ESMTP id 088677803A5; Fri, 23 Jun 2017 12:51:08 +0200 (CEST)
To: saag@ietf.org, OAuth WG <oauth@ietf.org>, IETF Tokbind WG <unbearable@ietf.org>
References: <8d869aa1-568e-788f-b8f9-b056fc5d771c@KingsMountain.com> <14050b8e-6cd9-9be7-6a1a-3d8cbe1f19cf@free.fr>
From: Denis <denis.ietf@free.fr>
Message-ID: <df3ed42c-909e-7ff7-9af4-f4a1f43a81cc@free.fr>
Date: Fri, 23 Jun 2017 12:51:16 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1
MIME-Version: 1.0
In-Reply-To: <14050b8e-6cd9-9be7-6a1a-3d8cbe1f19cf@free.fr>
Content-Type: multipart/alternative; boundary="------------2B9F9D64C442E497FC835ED4"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/unbearable/dn_tob6yiFjT5CQiTVhBb6tSVuI>
Subject: [Unbearable] New Special Publication 800-63-3 "Digital Identity Guidelines" Suite published
X-BeenThere: unbearable@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "\"This list is for discussion of proposals for doing better than bearer tokens \(e.g. HTTP cookies, OAuth tokens etc.\) for web applications. The specific goal is chartering a WG focused on preventing security token export and replay attacks.\"" <unbearable.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/unbearable>, <mailto:unbearable-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/unbearable/>
List-Post: <mailto:unbearable@ietf.org>
List-Help: <mailto:unbearable-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/unbearable>, <mailto:unbearable-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 23 Jun 2017 10:51:14 -0000

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: 

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/


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