This looks reasonable; a few nits and comments inline.
On Wed, Dec 17, 2014 at 2:44 AM, Ryan Kelly <[email protected]> wrote:
>
> Hi All,
>
>
> A limitation of the current FxA OAuth flow is that OAuth reliers cannot
> get access to the user's encryption keys.
>
>
<snip>
> 2) Service-specific keys
>
> Each OAuth service provider should be able to have a derived key that is
> specific to that service, and is provided to any relier that is granted
> access to the service.
>
> As a concrete example, suppose that the readinglist service wants to
> encrypt some fields in the data stored on its server. As a matter of
> policy, we decide that we can tolerate loss of such data in the event of a
> password reset, so we define the key for scope "readinglist" as:
>
> kS = HKDF(kB, "identity.mozilla.com/picl/v1/keys/service/readinglist")
>
> Any relier that is granted access to scope "readinglist" should also be
> able to get this derived key, in order to properly access the data stored
> in the service.
>
>
> These two types completely define the encryption keys available to a
> relier. During a key-enabled oauth flow they should somehow receive:
>
> * the relier-specific kAr and kBr
> * any scope-specific keys defined for the scopes they are granted
>
I'm a little concerned that the set of scope-specific keys is unbounded,
and we have a public-key encryption for each one. That's very expensive.
Perhaps we want to limit the set of keys provided, or do just one
encryption for the entirety of the keys: {} data.
> Any use-cases not covered by one of these two types of derived key?
>
>
>
> A key-fetching OAuth dance:
> ===========================
>
> The real trick, of course, is safely deriving these keys and delivering
> them to the relier. I posit that this must be done as part of the OAuth
> dance. The content-server is the only thing that can prompt the user for
> their password in order to derive the keys, and the content-server only
> gets involved during the OAuth dance.
>
> We have a couple of options here, but I'll sketch out the one I like best
> (large chunks of which are thanks to Alexis):
>
>
> 1) When initiating the OAuth dance, the relier generates a public/private
> keypair, stores the private key in its application state, and includes the
> public key in the OAuth authorization request:
>
> GET /v1/authorization?client_id=AAA&scope=readinglist&keyfetch=PUBKEY
>
>
> 2) We're redirected to the content-server OAuth page, which does its usual
> solicitation of user permission, prompts for the user's password if
> necessary to obtain kA and kB, and derives the appropriate scoped
> encryption keys.
>
A little off topic, but what happens if the user wants to convey "you can
only see one key" or "no keys at all"?
<snip>
* There's a whole lot of potential for crypto to be done wrong
> here! It's pretty scary stuff and smells kinda fragile.
>
>
> I'd love to avoid public-key crypto here...perhaps there's a way for the
> content-server to generate a symmetric encryption secret and communicate it
> directly back to the relier without it transiting our servers?
>
I'm a little concerned about doing a lot of public-key crypto in the
fxa-content-server. It's getting ... unwieldy.
A few crypto nits:
* specing key interchange and encrypted forms is annoying. I reverse
engineered jwCrypto for Firefox for Android's FxA implementation. Is
JW{E,T,?} ready yet?
* is there any request and response integrity at the fxa-oauth protocol
level? I'm going to assume encrypt() is encrypt-and-HMAC throughout. How
does the relier know the keys in /authenticate are the same as those in
/token? Is this kind of state something that reliers expect to maintain
already?
> Chris also suggested that the encryption keys may not need to transit the
> server at all, but could instead be communicated from content-server to
> relier via a client-side postMessage API. I don't know much about
> postMessage but it sounds worth exploring.
>
> Details aside, will this sort of enhanced OAuth dance give us what we want?
>
> Does this sound appropriately terrifying to everyone?
>
Yes! But this is also the most though-provoking email thread I've
participated on in a month, so thank you for preparing the proposal.
Nick
_______________________________________________
Dev-fxacct mailing list
[email protected]
https://mail.mozilla.org/listinfo/dev-fxacct
