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

Kathleen Moriarty <> Wed, 18 February 2015 22:02 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 11DEC1A1B0C for <>; Wed, 18 Feb 2015 14:02:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.699
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id tyeAapeYV4PG for <>; Wed, 18 Feb 2015 14:02:39 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 02B2A1A1AE2 for <>; Wed, 18 Feb 2015 14:02:39 -0800 (PST)
Received: by labpn19 with SMTP id pn19so4120046lab.4 for <>; Wed, 18 Feb 2015 14:02:37 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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 with SMTP id dt9mr1450871lbc.56.1424296957362; Wed, 18 Feb 2015 14:02:37 -0800 (PST)
Received: by with HTTP; Wed, 18 Feb 2015 14:02:37 -0800 (PST)
In-Reply-To: <>
References: <> <>
Date: Wed, 18 Feb 2015 17:02:37 -0500
Message-ID: <>
From: Kathleen Moriarty <>
To: Sam Hartman <>
Content-Type: multipart/alternative; boundary="001a11c3698632c750050f63fa97"
Archived-At: <>
Cc: "" <>
Subject: Re: [OAUTH-WG] AD review of Draft-ietf-dyn-reg
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 18 Feb 2015 22:02:42 -0000

On Wed, Feb 18, 2015 at 4:45 PM, Sam Hartman <> wrote:

> >>>>> "Kathleen" == Kathleen Moriarty <>
> 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.


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.


> --Sam


Best regards,