>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 [email protected] https://lists.nongnu.org/mailman/listinfo/nmh-workers
