>>>>> "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
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
