Re: [OAUTH-WG] Stephen Farrell's Discuss on draft-ietf-oauth-amr-values-05: (with DISCUSS)

Stephen Farrell <stephen.farrell@cs.tcd.ie> Thu, 02 February 2017 00:24 UTC

Return-Path: <stephen.farrell@cs.tcd.ie>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9956012960A; Wed, 1 Feb 2017 16:24:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.499
X-Spam-Level:
X-Spam-Status: No, score=-7.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie
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 nGO_gtqNvs-4; Wed, 1 Feb 2017 16:24:15 -0800 (PST)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D6C0D129577; Wed, 1 Feb 2017 16:24:14 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 5A51ABE58; Thu, 2 Feb 2017 00:24:12 +0000 (GMT)
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H6TffSlAKAu3; Thu, 2 Feb 2017 00:24:06 +0000 (GMT)
Received: from [10.87.48.75] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 22C42BE3E; Thu, 2 Feb 2017 00:24:06 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1485995046; bh=LLxbcnD5NA9NU4a+qgTI5C+MxDA+sDDJWlQTGouCdwY=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=fTUmpo3SPFjaq6QJZYbjTBwjgQjoUQZiOrLu2hJDf+J513Im/OqN9mV+bnnaO0kMJ KWrwHPjveQpz50ERWY8qkmDwEObbWWKujX3WWgTApVD8XAriEvGdv9zVKHHyIA4dvh CRdiB2/506wZNhbGwKlupVSi5CrgWDtHeOPdRBfQ=
To: Mike Jones <Michael.Jones@microsoft.com>, Anthony Nadalin <tonynad@microsoft.com>, joel jaeggli <joelja@bogus.com>, The IESG <iesg@ietf.org>
References: <148587998454.2480.4991718024003414319.idtracker@ietfa.amsl.com> <c0e62125-14e6-2390-87e3-72a2422f732f@bogus.com> <d9d0f5ae-6dcd-98cc-6113-96e937332b60@cs.tcd.ie> <BN3PR03MB23559422F9C2474DB04094FEF54D0@BN3PR03MB2355.namprd03.prod.outlook.com> <27d6181c-eb72-b17b-ed18-db018991e44c@cs.tcd.ie> <SN1PR0301MB2029EF1377E24CD330C5C929A64C0@SN1PR0301MB2029.namprd03.prod.outlook.com> <BN3PR03MB2355204C821E8E1807143F95F54C0@BN3PR03MB2355.namprd03.prod.outlook.com>
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Message-ID: <268ffcf0-2f90-049e-1a3c-03b39d62c338@cs.tcd.ie>
Date: Thu, 2 Feb 2017 00:24:05 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0
MIME-Version: 1.0
In-Reply-To: <BN3PR03MB2355204C821E8E1807143F95F54C0@BN3PR03MB2355.namprd03.prod.outlook.com>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms040906030700080104080206"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/3j7w1XNILkA3h-taFMbJDWI4C_0>
Cc: "oauth-chairs@ietf.org" <oauth-chairs@ietf.org>, "draft-ietf-oauth-amr-values@ietf.org" <draft-ietf-oauth-amr-values@ietf.org>, "oauth@ietf.org" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Stephen Farrell's Discuss on draft-ietf-oauth-amr-values-05: (with DISCUSS)
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/oauth/>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 02 Feb 2017 00:24:17 -0000


On 02/02/17 00:21, Mike Jones wrote:
> Thanks, Tony.  I can add that reference.
> 
> Stephen, the sets of initial values were chosen from those used in
> practice by Microsoft and Google in real deployments.

Genuine questions: do you aim to have interop between those
deployments? What if I wanted to write code that'd interop
with msft or google?

S.

> 
> About "otp", there are existing use cases for indicating that an OTP
> was used.  I'm not aware of any of these use cases where the
> distinction between TOTP and HOTP is important.  Thus, having "otp"
> now makes sense, where having "hotp" and "totp" now doesn't.
> 
> Stephen, this may seem like splitting hairs, but the registry
> instructions for "Specification Document(s)" are about having a
> reference for the document where the Authentication Method Reference
> Name (such as "otp") is defined.  In all cases for the initial
> values, this is the RFC-to-be, so the registry instructions are
> satisfied.  If someone were, for instance, to define the string
> "hotp", it would be incumbent on the person requesting its
> registration to provide a URL to the document where the string "hotp"
> is defined.  Also having a reference to RFC 4226 in that document
> would be a good thing, but that isn't what the registry instructions
> are about.
> 
> All that said, I can look at also finding appropriate references for
> the remaining values that don't currently have them.  (Anyone got a
> good reference for password or PIN to suggest, for instance?)
> 
> -- Mike
> 
> -----Original Message----- From: Anthony Nadalin Sent: Wednesday,
> February 1, 2017 4:10 PM To: Stephen Farrell
> <stephen.farrell@cs.tcd.ie>;; Mike Jones
> <Michael.Jones@microsoft.com>;; joel jaeggli <joelja@bogus.com>;; The
> IESG <iesg@ietf.org>; Cc: oauth-chairs@ietf.org;
> draft-ietf-oauth-amr-values@ietf.org; oauth@ietf.org Subject: RE:
> [OAUTH-WG] Stephen Farrell's Discuss on
> draft-ietf-oauth-amr-values-05: (with DISCUSS)
> 
> NIST asked for the addition of IRIS (as they are seeing more use of
> IRIS over retina due to the accuracy of iris)  as they have been
> doing significant testing on various iris devices and continue to do
> so, here is a report that NIST released
> http://2010-2014.commerce.gov/blog/2012/04/23/nist-iris-recognition-report-evaluates-needle-haystack-search-capability.html
> 
> 
> -----Original Message----- From: Stephen Farrell
> [mailto:stephen.farrell@cs.tcd.ie] Sent: Wednesday, February 1, 2017
> 2:26 PM To: Mike Jones <Michael.Jones@microsoft.com>;; joel jaeggli
> <joelja@bogus.com>;; The IESG <iesg@ietf.org>; Cc:
> oauth-chairs@ietf.org; draft-ietf-oauth-amr-values@ietf.org;
> oauth@ietf.org Subject: Re: [OAUTH-WG] Stephen Farrell's Discuss on
> draft-ietf-oauth-amr-values-05: (with DISCUSS)
> 
> 
> Hi Mike,
> 
> On 01/02/17 17:00, Mike Jones wrote:
>> Thanks for the discussion, Stephen.
>> 
>> To your point about "otp", the working group discussed this very 
>> point.  They explicitly decided not to introduce "hotp" and "totp" 
>> identifiers because no one had a use case in which the distinction 
>> mattered.
> 
> Then I'm not following why adding "otp" to the registry now is a good
> plan.
> 
> If there's a use-case now, then adding an entry with a good reference
> to the relevant spec seems right.
> 
> If there's no use-case now, then not adding it to the registry seems
> right. (Mentioning it as a possible future entry would be fine.)
> 
> I think the same logic would apply for all the values that this spec
> adds to the registry. Why is that wrong?
> 
>> Others can certainly introduce those identifiers and register them
>> if they do have such a use case, once the registry has been
>> established.  But the working group wanted to be conservative about
>> the identifiers introduced to prime the registry, and this is such
>> a case.
>> 
>> What identifiers to use and register will always be a balancing
>> act. You want to be as specific as necessary to add practical and
>> usable value, but not so specific as to make things unnecessarily
>> brittle.
> 
> Eh... don't we want interop? Isn't that the primary goal here?
> 
>> While some might say there's a difference between serial number 
>> ranges of particular authentication devices, going there is
>> clearly in the weeds.  On the other hand, while there used to be an
>> "eye" identifier, Elaine Newton of NIST pointed out that there are 
>> significant differences between retina and iris matching, so "eye" 
>> was replaced with "retina" and "iris".  Common sense informed by 
>> actual data is the key here.
> 
> That's another good example. There's no reference for "iris." If that
> is used in some protocol, then what format(s) are expected to be
> supported? Where do I find that spec? If we can answer that, then
> great, let's add the details. If not, then I'd suggest we omit "iris"
> and leave it 'till later to add an entry for that. And again,
> including text with "iris" as an example is just fine, all I'm asking
> is that we only add the registry entry if we can meet the same bar
> that we're asking the DE to impose on later additions.
> 
> And the same for all the others...
> 
> Cheers, S.
> 
> 
>> 
>> The point of the registry requiring a specification reference is
>> so people using the registry can tell where the identifier is
>> defined. For all the initial values, that requirement is satisfied,
>> since the reference will be to the new RFC.  I think that aligns
>> with the point that Joel was making.
>> 
>> Your thoughts?
>> 
>> -- Mike
>> 
>> -----Original Message----- From: OAuth 
>> [mailto:oauth-bounces@ietf.org] On Behalf Of Stephen Farrell Sent: 
>> Wednesday, February 1, 2017 7:03 AM To: joel jaeggli 
>> <joelja@bogus.com>;; The IESG <iesg@ietf.org>; Cc: 
>> oauth-chairs@ietf.org; draft-ietf-oauth-amr-values@ietf.org; 
>> oauth@ietf.org Subject: Re: [OAUTH-WG] Stephen Farrell's Discuss
>> on draft-ietf-oauth-amr-values-05: (with DISCUSS)
>> 
>> 
>> 
>> On 01/02/17 14:58, joel jaeggli wrote:
>>> On 1/31/17 8:26 AM, Stephen Farrell wrote:
>>>> Stephen Farrell has entered the following ballot position for 
>>>> draft-ietf-oauth-amr-values-05: Discuss
>>>> 
>>>> When responding, please keep the subject line intact and reply
>>>> to all email addresses included in the To and CC lines. (Feel
>>>> free to cut this introductory paragraph, however.)
>>>> 
>>>> 
>>>> Please refer to 
>>>> https://www.ietf.org/iesg/statement/discuss-criteria.html for 
>>>> more information about IESG DISCUSS and COMMENT positions.
>>>> 
>>>> 
>>>> The document, along with other ballot positions, can be found 
>>>> here: 
>>>> https://datatracker.ietf.org/doc/draft-ietf-oauth-amr-values/
>>>> 
>>>> 
>>>> 
>>>> ---------------------------------------------------------------------
>>>>
>>>>
>
>>>> 
-
>>>> DISCUSS: 
>>>> ---------------------------------------------------------------------
>>>>
>>>>
>
>>>> 
-
>>>> 
>>>> This specification seems to me to break it's own rules. You
>>>> state that registrations should include a reference to a
>>>> specification to improve interop. And yet, for the strings
>>>> added here (e.g. otp) you don't do that (referring to section 2
>>>> will not improve interop) and there are different ways in which
>>>> many of the methods in section 2 can be done. So I think you
>>>> need to add a bunch more references.
>>> 
>>> Not clear to me that the document creating the registry needs to
>>>  adhere to the rules for further allocations in order to
>>> prepoulate the registry. that is perhaps an appeal to future
>>> consistency.
>> 
>> Sure - I'm all for a smattering of inconsistency:-)
>> 
>> But I think the lack of specs in some of these cases could impact
>> on interop, e.g. in the otp case, they quote two RFCs and yet only
>> have one value. That seems a bit broken to me, so the discuss isn't
>> really about the formalism.
>> 
>> S.
>> 
>> 
>>>> 
>>>> 
>>>> 
>>> 
>>> 
>> 
>