On 24/12/2014 16:22, Nicholas Alexander wrote:
On Wed, Dec 17, 2014 at 2:44 AM, Ryan Kelly <[email protected]
<mailto:[email protected]>> wrote:
A limitation of the current FxA OAuth flow is that OAuth reliers
cannot get access to the user's encryption keys.
<snip>
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"?
We face a similar problem if the user wants to convey "you can't have
all the scopes you requested". We've managed to avoid it so far because
we trust our set of reliers to ask for the right scopes, and don't give
the user a chance to intervene.
I imagine the solution will ultimately boil down to: the relier must
check whether it got back the scopes (and keys) that it actually
requested, and fail out gracefully if not.
FWIW, keeping this simple is one of the reasons that I proposed tying
keys directly to scopes. Some scopes imply access to a key, some do
not. The relier is either granted the scope and any associated key, or
it gets neither.
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?
Indeed. This is very much TBD.
* is there any request and response integrity at the fxa-oauth protocol
level?
Nope.
I'm going to assume encrypt() is encrypt-and-HMAC throughout.
Aye, thanks for making that explicit.
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?
Broadly yes, reliers are already responsible for tunneling their own app
state through the oauth dance.
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.
Thanks for the detailed comments!
Hopefully we can kick around some of these ideas on background cycles in
Q1, and revisit it all a bit more concretely later in the year.
Cheers,
Ryan
_______________________________________________
Dev-fxacct mailing list
[email protected]
https://mail.mozilla.org/listinfo/dev-fxacct
