[secdir] SECDIR Review of draft-ietf-oauth-amr-values-04

Catherine Meadows <catherine.meadows@nrl.navy.mil> Thu, 01 December 2016 16:19 UTC

Return-Path: <catherine.meadows@nrl.navy.mil>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FC9F127058; Thu, 1 Dec 2016 08:19:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.797
X-Spam-Level:
X-Spam-Status: No, score=-4.797 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-2.896, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MZhvpAqTAAYH; Thu, 1 Dec 2016 08:19:43 -0800 (PST)
Received: from ccs.nrl.navy.mil (mx0.ccs.nrl.navy.mil [IPv6:2001:480:20:118:118::211]) (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 A98B11294C5; Thu, 1 Dec 2016 08:19:37 -0800 (PST)
Received: from ashurbanipal.fw5540.net (fw5540.nrl.navy.mil [132.250.196.100]) by ccs.nrl.navy.mil (8.14.4/8.14.4) with ESMTP id uB1GJZHY017982 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Thu, 1 Dec 2016 11:19:35 -0500
From: Catherine Meadows <catherine.meadows@nrl.navy.mil>
Content-Type: multipart/alternative; boundary="Apple-Mail=_DCFDC443-C4CC-4C92-B6FE-1CF9E721AF03"
Date: Thu, 01 Dec 2016 11:19:35 -0500
Message-Id: <ABB46E70-4015-43B0-9364-0F32FD8FC9AB@nrl.navy.mil>
To: secdir@ietf.org, iesg@ietf.org, draft-ietf-oauth-amr-values.all@ietf.org
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
X-Mailer: Apple Mail (2.3124)
X-CCS-MailScanner: No viruses found.
X-CCS-MailScanner-Info: See: http://www.nrl.navy.mil/ccs/support/email
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/b582jgJriBg0cZrW9Yi7N7mesPI>
Subject: [secdir] SECDIR Review of draft-ietf-oauth-amr-values-04
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 01 Dec 2016 16:19:46 -0000

I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments.

This document establishes a registry for Authentication Method Reference (amr) values used by the OpenID protocol and defines an initial set of such values.   The amr claim is already defined and registered
in IANA; this document serves to implement it.  The amr provides a field in which information about the type of authentication being used is provided, using the amr values.

The authors of the document address both security and privacy concerns,  The privacy concern is that the amr claim provides information about the form of authentication used, which could have
privacy implications in some cases, and that this document does not provide any guidance as to how privacy-relevant credentials, such as biometric information, are stored and protected.  As the authors
point out, the latter is beyond the scope of the document.  

The security concerns are mainly derived from those  of the OpenID protocol.  The authors also warn that amr may be more brittle than another related claim, acr, since acr provides information about
whether a particular set of business rules were satisfied, while acm only tells you whether a particular type of authentication was used.  This could lead to a policy that relies on particular forms of authentication,
which would be harder to update as security needs change.  

I think that the authors have done a good job of addressing security and privacy concerns, and I don’t see any issues here. I consider this document ready.

Cathy Meadows



Catherine Meadows
Naval Research Laboratory
Code 5543
4555 Overlook Ave., S.W.
Washington DC, 20375
phone: 202-767-3490
fax: 202-404-7942
email: catherine.meadows@nrl.navy.mil <mailto:catherine.meadows@nrl.navy.mil>