I haven't drilled into any of the new code, and I confess ignorance of
OAUTH in general. My concern is about protecting the private key, and
my glancing read of the conversation says that, somewhere along the way,
an MH command has to unlock a private key and do a dance with a remote
host in order to obtain a token. This doesn't sound all that different
from, e.g., Kerberos, so the same caveats apply: keep the private key
private.
Weeeelll ... it's not quite like Kerberos. Let me be up front: I think
I can speak with some confidence regarding Kerberos, but I am relatively
new to OAuth.
In Kerberos, what gets sent over the wire (as far as nmh is concerned)
is an AP_REQ message. That's something constructed by the client-side
code, based on the ticket you get back from the Kerberos server and
some encrypted stuff you create yourself, using a key you got from the
Kerberos server. The important bit is that the AP_REQ has all of the
crypto done for you; it's safe to to send over the wire without any
additional encryption.
In OAuth, what gets sent over the wire is a "bearer token". That
consists of a little bit of JSON and an "access token". As a client,
you don't know what the format is of the access token; it's a cookie
as far as you're concerned. You might get an expiration time after
which the access token is no longer valid; when that happens, you talk
to a special web server using a "refresh token" to get a new access
token.
The key difference (pun intended) is that we're not really doing any
"key management", at least from a crypto persective, at all, because
as far as OAuth is concerned, there is no crypto. The access token
needs to be protected via TLS when it is sent over the wire. Think
of it as a funky password. On our side, we treat it like a password;
we store it in a file (like we do with passwords in .netrc) and pull
it out when we need it.
I don't want to get into weeds talking about OAuth; it's pecularities
are driven by the Web. From our side, think of it as the SASL PLAIN
mechanism, except that occasionally we fetch a new password out-of-band.
Without intending to offend anyone, I will suggest the OAUTH bits need
a thorough third-part review before being blessed with a merge into the
mainline code trunk.
Really, I think I took a good look at it. There's no "key management"
as it's generally understood by crypto people. It's pretty straightforward
once you grok OAuth. Other than the issues with passing the bearer token
via the command line from send(1) to post(8), I see no issues.
--Ken
_______________________________________________
Nmh-workers mailing list
Nmh-workers(_at_)nongnu(_dot_)org
https://lists.nongnu.org/mailman/listinfo/nmh-workers