Re: [http-auth] FW: New Version Notification for draft-woodworth-json-http-auth-00.txt

["Woodworth, John R" <[e-mail]>]

-----Original Message-----
From: Manger, James [mailto:[e-mail]]


Hi James,

First, thank you for the detailed feedback it is very much
appreciated.  It's actually eerie how your comments mirror
our own internal discussions on many points.

>
> The "password" variant sends the same info as BASIC, just with a
> different syntax. It is hard to see the point. Surely a normal
> BASIC header could be passed to client-side scripting just as
> easily as a re-formatted version?
>
> The "challenge" variant looks like it is trying to mimic the
> DIGEST scheme, with a different syntax, and with the crypto
> applied slightly differently. The crypto changes look more
> dangerous than helpful. DIGEST at least separated the concepts
> of a Hash from a MAC (Keyed Digest), even if the latter used
> the former in too simple a way. In DIGEST the password is hashed
> with the username and realm to form a secret key, but not in
> "challenge". A new spec today should use a proper MAC algorithm,
> such as HMAC.
>

Both of these similarities are actually intentional.  One of our
goals is to get a "usable framework" which is both JSON based and
can be easily extended.  Our rational for including something
basic-ish and digest-ish was that a framework not having comparable
features was dead out of the gate.  Early versions actually used
"basic" and "digest" types and borrowed even more heavily from each.
It was decided to avoid being *too* close in an attempt to cut down
on confusion.  Perhaps we should make this point obvious in the
introduction?

>
> Quirks from DIGEST seem to be repeated in "challenge", such as
> separate "nonce" and "opaque" members despite both being: chosen
> by the server; opaque to the client; hashed into the response;
> and returned to the server.
>

The opaque value is not strictly necessary for the authentication
portion and is expected to be _additional_ easily validated data the
server can use to simplify its session management.

To keep implementation requirements down for the server, our thought
was if the nonce (and other session data) could be self validated, a
table would not _need_ to be kept.  With no table, no shared memory
or other complications would need to be done among the multiple
threads and/ or multiple servers.  This opens itself to something
as simple as a CGI script.

>
> The highly recommended "nonce" construction looks poor. A 36-char
> random UUID just to provide uniqueness within the 10µs window of
> the time component (eg 1488442706.13154) is overkill.
>

Funny, this was added to avoid the whole "this is cryptographically
too weak" discussion :) .

>
> Hashing a
> concatenation of nonce parts and a secret is the sort of ad hoc
> crypto that should be avoided. Use a proper MAC algorithm instead.
>

We are definitely open to something like HMAC, our target here was
again to keep implementation effort minimal.  Thankfully, we have
really good MIT compatible libraries for the project which spawned
this draft so I guess it's reasonable to assume this is not an
issue.  We just wanted to get additional input from this group
before moving in that direction.

>
> JSON has arrays so why not use an array for the "algorithms"
> member, instead of a comma-separated string with a rule to ignore
> whitespace?
>

No strong reason.  Our rational was to keep the object from
becoming too much of a nested mess but we are in agreement here.

>
> The mix of base64, lowercase-hex, and UUID encoding; plus commas,
> slashes, hyphens, and colons as separators is a bit messy.
>

I guess the nonce could just as easily be a sub-object.

Somehow, this was expected to allow a developer to run some really
simple cli tools to manually dissect, inspect and verify all the
parts of the process.

As you may have noticed, 'simplicity in implementation' is a common
theme.  It sounds like crypto comes easily to you but I have found
it to be a difficult topic for many developers.  Keeping simple
components which can each be easily checked via readily available
tools like 'sha256sum' and 'jq' is an attempt to simplify the
process.

This, in my mind at least should make for fewer conceptual
problems and fewer problems makes for less buggy implementations.

Having said that, I am always open to being wrong.

>
> Suggesting window.AuthHandler() as a place to host handlers
> (without specifying actual APIs) sounds like it will ruin this
> place for use once something interoperable is actually defined.
>

This is true.  As silly as it may sound, we were hoping to keep
the page-count down to around 10.  We have another draft which
is roughly 35 pages and it is difficult to get that much of
someone's time for feedback.  We are currently sitting at around
15 and every minor detail seems to add 5 pages.

That said, we will expand on this topic in hopes we miss shooting
either foot.

>
> Your pretty JSON format with commas at the start of the next line
> (instead of the end of the previous line) is a cute convention.
>

Thanks.  I wish I could take credit for it but I found this little
gem as part of a code-style requirements doc for contributing to
some JavaScript project a while back and have been searching for
it again to give proper attribution.

It is by far the one JS tip that's saved me the most frustration
as trailing commas are simply death waiting to happen };{> .


Thanks,
John

>
>       {
>          "type"     : "password"
>         ,"username" : "MyUser"
>         ,"password" : "MyPassword"
>       }
>
> --
> James Manger
>

-- THESE ARE THE DROIDS TO WHOM I REFER:
This communication is the property of CenturyLink and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments.