Re: SCRAM inplementation

On 31/03/17 14:31, Dave Cramer wrote:
> Some of you may be aware that postgres 10 will have an additional
> authentication method called SCRAM
>
> Alvaro has graciously offered to implement this for JDBC. I mention
> this because if anyone is in the process of implementing it perhaps we
> should discuss it and break it up into parts.
>
> Also this means we are going to be adding some dependencies. Alvaro
> can you talk about which dependencies you are contemplating ?
>
> Regards,
>
> Dave Cramer

Hi Dave, everybody.

Yes, I happily offered to work on this :) I already started working
a bit, but can't make hard promises on a deadline. If anyone's
interested in helping, please let me know.

Here's my initial ideas:

* Write both a client and server implementation. pgjdbc will only
require the former, of course, but having both will be great for testing.
* Do so as an independent library, also as an independent repository on
Github. This will help its reuse and testing by independent projects. I
presume it will have at least three different artifacts, a scram-common,
scram-server and scram-client. Only the latter will be directly imported
as a direct dependency by pgjdbc.
* The implementation will *not* provide support for message sending
and/or serialization. Only message generation and parsing (after all,
messages are only strings, so it's easy). This is meant to be easily
reused, but will of course require some glue code on the pgjdbc side.
* Channel biding will not be on the first version. It is not used in
PostgreSQL 10 either (as of today).
* Both SHA-1 and SHA-256 will be implemented (yeah, I know about SHA-1
collision, but it's still an RFC and adding it is a one-liner so... I
leave the decision to the users). PG 10 will only ship with SHA-256,
though, AFAIK.
* First version will not implement SaslPrep (neither PG10 does). When it
will do.... I will probably do a separate repository for
StringPrep/SaslPrep code, as it is again of a very reusable nature
outside of the SCRAM (and of cours pgjdbc) projects.
* I have tried to lay out the code so that no further external
dependencies are required. It might be difficult. There are some
libraries out there that could help (for example on the
StringPrep/SaslPrep side). There could be more dependencies used, but
only for testing.
* I want to make a consideration about writing Java6 vs Java8 code.
Unless there would be general agreement on moving pgjdbc to Java8 (and
this could be a topic on itself), I will develop it for Java6. However,
there are some downsides:
- There's no "official" API for Base64 in JDK6, and I won't do it
by hand. Either apache-commons-codec is used or JDK 6's
javax.xml.bind.DatatypeConverter methods are used. I will use the
latter, but it is not an ideal approach. Java8 has a new Base64 class
for this.
- Both SHA-1 and SHA-256 and their corresponding HMACs are
supported in both versions. But the "Hi" function defined in the RFC
(aka PBKDF2) is not supported in Java6 but is implemented in Java8:
SecretKeyFactory.getInstance("PBKDF2WithHmacSHA256"). It shouldn't be
hard to implement it "by hand", having the hmac functions available, but
this is clearly my limit into how much crypto code I would write by hand
(not that I wouldn't like to, it's fun, but I favor a secure
implementation here). The alternative is to bring another library, of
course.
- The client API will contain some FunctionalInterfaces I will not
be able to annotate as such if in Java6.
So... I don't want to spur a heavy debate on Java6 vs Java8, and maybe
that should go on a separate thread, but... thinking of it why not?
There are indeed many versions (up to and including 42) of pgjdbc which
work for Java6, are fully featured, and mature. While they are developed
for a platform EOLed for several years. Does it make real sense to
continue developing new versions with this platform in mind? Are there
very strong reasons to remain Java6-compatible for future versions?

Please let me know your thoughts.

Regards,

Álvaro

--

Álvaro Hernández Tortosa

-----------
<8K>data