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

[Sam Hartman <[e-mail]>]

>>>>> "Kathleen" == Kathleen Moriarty <[e-mail]> 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