On Wed, Feb 18, 2015 at 4:45 PM, Sam Hartman <hartmans-i...@mit.edu> wrote:
> >>>>> "Kathleen" == Kathleen Moriarty <kathleen.moriarty.i...@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
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
