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

[Kathleen Moriarty <[e-mail]>]

On Wed, Feb 18, 2015 at 4:45 PM, Sam Hartman <[e-mail]> wrote:

> >>>>> "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,

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