Return-Path: 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 ; 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 ; 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 ; 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; 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: 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: "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2015 22:02:42 -0000 --001a11c3698632c750050f63fa97 Content-Type: text/plain; charset=UTF-8 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. > 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 --001a11c3698632c750050f63fa97 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Feb 18, 2015 at 4:45 PM, Sam Hartman <hartmans-ietf@mit.ed= u> wrote:
>>>>&= gt; "Kathleen" =3D=3D Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> wri= tes:

=C2=A0 =C2=A0 Kathleen> registry, but setting HTTP Basic as the default = seems like
=C2=A0 =C2=A0 Kathleen> a really bad choice. HOBA is on it's way to = becoming an
=C2=A0 =C2=A0 Kathleen> RFC from the HTTPAuth working group.=C2=A0 HTTPA= uth also has an
=C2=A0 =C2=A0 Kathleen> updated version of Basic that is in IETF last ca= ll, but I
=C2=A0 =C2=A0 Kathleen> know you are pointing to the OAuth 2.0 document,= so it
=C2=A0 =C2=A0 Kathleen> would be that document that gets updated and not= this
=C2=A0 =C2=A0 Kathleen> draft.=C2=A0 The new version of HTTP Basic fixes= some
=C2=A0 =C2=A0 Kathleen> internationalization problems and spells out the= security
=C2=A0 =C2=A0 Kathleen> issues much more clearly, so it probably doesn&#= 39;t matter
=C2=A0 =C2=A0 Kathleen> too much to update the reference, but maybe make= s it more
=C2=A0 =C2=A0 Kathleen> clear that basic is not a secure form of authent= ication.
=C2=A0 =C2=A0 Kathleen> Can you provide some justification as to why thi= s is okay
=C2=A0 =C2=A0 Kathleen> to set basic as the default and add that to the = draft?
=C2=A0 =C2=A0 Kathleen> Section 2.3.1 of OAuth 2.0 just says this MUST b= e
=C2=A0 =C2=A0 Kathleen> implemented, but that any HTTP schemes can be us= ed.=C2=A0 Why
=C2=A0 =C2=A0 Kathleen> not register another method and use that instead= as the
=C2=A0 =C2=A0 Kathleen> default?=C2=A0 You could use digest and there is= library
=C2=A0 =C2=A0 Kathleen> support.=C2=A0 It's not a great answer, but = slightly better
=C2=A0 =C2=A0 Kathleen> than passwords with basic.=C2=A0 You could regis= ter HOBA and
=C2=A0 =C2=A0 Kathleen> use that instead, the only downside is limited l= ibrary
=C2=A0 =C2=A0 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 i= ssues
in deploying credentials by this point.

Yes, you absolutely can choose whatever you like as the authentication
scheme for a single-use account.=C2=A0 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 b= e true.

However, a lot of deployments re-use accounts.=C2=A0 That is, the
deploymentwill allow some form of single sign-on.=C2=A0 The same account ma= y
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=C2=A0 = NTLM
hashes (read Active Directory) that are my credentials.=C2=A0 (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=C2=A0 I've been accumulating as I sign up users for the last few y= ears,
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.=C2=A0 I can t= ry
various normalizations, try code-page conversions, rehash, whatever.
If your client implements scram, and I have NTLM, we're never going to<= br> be able to talk.=C2=A0 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.=C2=A0 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.=C2=A0 Anything else from httpauth will fall squarely int= o
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<= br> 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.=C2=A0 This is the wrong place to fight that battle.

Sam,

You may have missed part of= the thread.=C2=A0 I did not ask the WG to fix it here, just noted that I d= on't like that passwords is the best that we can do and there is no oth= er more secure option registered.=C2=A0 The WG will take a look at this and= see if other options are feasible.=C2=A0 An approach Justin is working on = was provided, but I haven't had time to read that yet.=C2=A0 If somethi= ng 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=C2=A0

--Sam



--

Best regards,
Kathleen
--001a11c3698632c750050f63fa97--