Re: [OAUTH-WG] AD review of Draft-ietf-dyn-reg

Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> Wed, 18 February 2015 22:02 UTC

Return-Path: <kathleen.moriarty.ietf@gmail.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11DEC1A1B0C for <oauth@ietfa.amsl.com>; Wed, 18 Feb 2015 14:02:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
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 tyeAapeYV4PG for <oauth@ietfa.amsl.com>; Wed, 18 Feb 2015 14:02:39 -0800 (PST)
Received: from mail-la0-f51.google.com (mail-la0-f51.google.com [209.85.215.51]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 02B2A1A1AE2 for <oauth@ietf.org>; Wed, 18 Feb 2015 14:02:39 -0800 (PST)
Received: by labpn19 with SMTP id pn19so4120046lab.4 for <oauth@ietf.org>; Wed, 18 Feb 2015 14:02:37 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=fk3GHDVDN9rmJfXC9dkJzBPiZ7/cUpPcLZgJ2qdz+S0=; b=m4IcUhto1m3pfRF8+IGegH9XSdYoqw9AI+4KJCv8edangFdNxNMCuWavTFD69fvA61 hWFEnjDLW4L8wsg/AralmhStqDNEajtfZKnO+T4bqWJoHhQPf/ltxgpAgMeLKpJF2DO8 llH2XNGTcwo/T1aKrhCZYPPmJ+FmxbncDvq4q1wWStsc1+LLrDxQ7I/BQHoOXrMx+Nfq jGsHrOUPh4rcIRzY6ErtVThHsv135nEZg4S1ERruQ0hQxH9xxPmnYi3U7uJlbscBSkFh jKJcMyBXga2YxbicmQYcIc4leIv0LPC0K2LG2/xtmE+1LtmrjpyqqbumRAj0QXzTlfxb ofGA==
MIME-Version: 1.0
X-Received: by 10.112.181.41 with SMTP id dt9mr1450871lbc.56.1424296957362; Wed, 18 Feb 2015 14:02:37 -0800 (PST)
Received: by 10.112.167.101 with HTTP; Wed, 18 Feb 2015 14:02:37 -0800 (PST)
In-Reply-To: <tsl61ayopwd.fsf@mit.edu>
References: <CAHbuEH587HcqaqTMrmLPXQimRAaS2j1Uv+BC-0UHeyBwC8+3Uw@mail.gmail.com> <tsl61ayopwd.fsf@mit.edu>
Date: Wed, 18 Feb 2015 17:02:37 -0500
Message-ID: <CAHbuEH4XezMK8OjKNTezoirsnRBJjAK1Rqh_WKQ3D_KaKuKyiQ@mail.gmail.com>
From: Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com>
To: Sam Hartman <hartmans-ietf@mit.edu>
Content-Type: multipart/alternative; boundary=001a11c3698632c750050f63fa97
Archived-At: <http://mailarchive.ietf.org/arch/msg/oauth/cir0CKxCd1Y66Mfgn2yLI4WqqNM>
Cc: "oauth@ietf.org" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] AD review of Draft-ietf-dyn-reg
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
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: <http://www.ietf.org/mail-archive/web/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: Wed, 18 Feb 2015 22:02:42 -0000

On Wed, Feb 18, 2015 at 4:45 PM, Sam Hartman <hartmans-ietf@mit.edu> wrote:

> >>>>> "Kathleen" == Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com>
> writes:
>
>     Kathleen> registry, but setting HTTP Basic as the default seems like
>     Kathleen> a really bad choice. HOBA is on it's way to becoming an
>     Kathleen> RFC from the HTTPAuth working group.  HTTPAuth also has an
>     Kathleen> updated version of Basic that is in IETF last call, but I
>     Kathleen> know you are pointing to the OAuth 2.0 document, so it
>     Kathleen> would be that document that gets updated and not this
>     Kathleen> draft.  The new version of HTTP Basic fixes some
>     Kathleen> internationalization problems and spells out the security
>     Kathleen> issues much more clearly, so it probably doesn't matter
>     Kathleen> too much to update the reference, but maybe makes it more
>     Kathleen> clear that basic is not a secure form of authentication.
>     Kathleen> Can you provide some justification as to why this is okay
>     Kathleen> to set basic as the default and add that to the draft?
>     Kathleen> Section 2.3.1 of OAuth 2.0 just says this MUST be
>     Kathleen> implemented, but that any HTTP schemes can be used.  Why
>     Kathleen> not register another method and use that instead as the
>     Kathleen> default?  You could use digest and there is library
>     Kathleen> support.  It's not a great answer, but slightly better
>     Kathleen> than passwords with basic.  You could register HOBA and
>     Kathleen> use that instead, the only downside is limited library
>     Kathleen> support at the moment.
>
>
> I'm disappointed to be reading the above, particularly the last
> sentence, today.
> I'd hope that we'd have a better wide-spread understanding of the issues
> in deploying credentials by this point.
>
> Yes, you absolutely can choose whatever you like as the authentication
> scheme for a single-use account.  If my account will only be used with a
> particularly dynamically registration then I probably can get away with
> choosing whatever I want as a default authentication and statements like
> "the only down-side will be limited library availability," will be true.
>
> However, a lot of deployments re-use accounts.  That is, the
> deploymentwill allow some form of single sign-on.  The same account may
> be used for an oauth dynamic registration as well as a bunch of other
> things.
> Even more of an issue, the backend database of credentials may already
> exist and may not be defined by this particular application.
>
> Digest is absolutely impossible to use if I've got a database of  NTLM
> hashes (read Active Directory) that are my credentials.  (In the
> particular case of AD and digest, you probably have a solution if you
> are using Microsoft's implementation.)
> However, if I've got some relational (or nosql) database storing hashes
> that  I've been accumulating as I sign up users for the last few years,
> I can only use authentication schemes compatible with those hashes.
>
>
> The huge deployment advantage of basic is that if you present me the
> password, I can match against whatever I have on the backend.  I can try
> various normalizations, try code-page conversions, rehash, whatever.
> If your client implements scram, and I have NTLM, we're never going to
> be able to talk.  Me implementing scram doesn't help if that's not how
> I've got credentials stored.
>
> Put another way, end protocols like this are not the right place to
> fight passwords.  You transition credential technologies at the
> deployment level, not at the protocol level.
>
> For interoperability in something like this we're likely going to do no
> better than basic.  Anything else from httpauth will fall squarely into
> the category of MUST BUT WE KNOW YOU WON't for some significant
> deployments.
>
> What I've said above doesn't apply particularly to protocols where the
> credentials will not be reused.
>
> I'd be happy to talk some time about strategies for giving deployments
> the tools they need to move their credential interface away from
> passwords, but it does need to be thought of as a deployment issue
> crossing all the applications and protocols that a set of credentials
> use.  This is the wrong place to fight that battle.
>

Sam,

You may have missed part of the thread.  I did not ask the WG to fix it
here, just noted that I don't like that passwords is the best that we can
do and there is no other more secure option registered.  The WG will take a
look at this and see if other options are feasible.  An approach Justin is
working on was provided, but I haven't had time to read that yet.  If
something gets done, it was already agreed that it would be in a separate
draft, I did not ask for it to be done here.

Thanks,
Kathleen

>
> --Sam
>



-- 

Best regards,
Kathleen