On Fri, Jul 4, 2014 at 4:33 AM, Shane Tomlinson <[email protected]>
wrote:
> IIUC, the core problem you are trying to solve arises because the user is
> being asked to grant the RP authorization to two distinct service providers
> in a single oauth transaction, and a single token would allow one service
> provider to masquerade as the user at the other service provider?
>
Yes, as well as any middleman along the way who is able to see the token,
such as if SSL isn't used or is cracked.
>
> First off, what is the crypto being used for? I think the answer is this
> sentence:
>
> > The next step was to consider using a secret token to sign a request, so
> that the original token is never revealed.
>
> In step 4, the RP receives a token from the OAuth server. In step 5, the
> RP takes that code, creates a pub/priv keypair, creates a bundle with the
> pubkey, the code, and the client_secret, signs the bundle with the privkey
> and ships it to the OAuth server?
Yep again.
> Does the RP then have to store the pub/priv key for this user/scope
> combination for all of eternity, or is this client side only?
As long as the user has an account at the RP, and the OAuth server hasn't
expired this "token". Similar to receiving a bearer token in typical
OAuth2, you need to hold on to it as long as you wish to make requests on
behalf of the user. Here, you'd just have 2 data pieces instead of one:
public and private key. With ed25519, these keys are small, so it shouldn't
affect storage much.
> If the priv key is sent to the RP, what threats exist if their server is
> compromised?
The private key shouldn't be sent anywhere: the RP should generate a
keypair, and then guard the private key. If their server is compromised,
the responsible thing to do would be to tell our OAuth server which "keys"
to destroy. If it were a big enough RP that we'd notice, we could also
destroy all "keys" associated with their client_id.
> What happens if the user is asked to re-authorize, is the same pub/priv
> key used, or is a new one generated?
You should create a new keypair if re-authorizing with the OAuth server,
such as to get additional scopes.
> Can the OAuth provider masquerade as the user anywhere they like?
>
The OAuth provider is the gatekeeper for the user. It has the power to say
if a certain pubkey has scopes or not. Therefore, it could potentially
create its own keypair and give itself any scopes it wanted; it's been
empowered to act as the user already.
>
> In step 6, what happens if the OAuth server already has a pubkey stored
> for the user/scope combination, does it reject the new one, clear the old
> one or store them both? If there are multiple keys stored, are old ones
> ever ejected?
>
The OAuth server will accept the new pubkey. The RP could ask the OAuth
server to destroy the old one. The old one might be cleaned up when it
expires, but we haven't yet specified an expiration of tokens, just "codes".
>
> In step 7, instead of passing the original token, the RP creates a new
> bundle that contains an encrypted/hashed version of the original token
> along with the scope? What info does the Profile server use to actually
> ensure the request is authorized? Does the Profile server need to share
> state with the OAuth server?
>
The signature is created similar to Hawk; it's all information found in the
request itself. Here's the info that's used to create the header:
{
type: 'header',
pubkey: fields.pubkey,
ts: fields.ts,
nonce: fields.nonce,
method: req.method.toUpperCase(),
resource: req.path,
host: req.hostname,
port: req.port || (req.protocol === 'https:' ? 443 : 80),
payload: req.payload ? payloadHash(req.payload, req.contentType) : ''
}
The service provider, such as the Profile server, can decode the signature
using the pubkey in the Authorization header, and compare with the info in
the request. Once it's sure the signature is authentic (we can provide
libraries to do this, such as the nodejs gryphon library already does), the
service provider just needs to ask the OAuth server for the scopes
permitted to that pubkey.
>
> I'm going on to step 8 - requesting info from FoxCoin, is it a repeat of
> step 7, just with a different service provider?
>
Yep, so the host, port, resource, timestamp, nonce, and payload would
likely differ, creating a different signature.
>
>
> Is there any notion of expiration? If my device has a magic priv key to
> FoxCoin, and then is stolen, will the thief forever have access to my
> FoxCoin account?
>
The pubkey/token can be manually removed from OAuth via POST /v1/destroy.
FoxCoin could notice and do this, or we also would like to have a dashboard
that allows the user to see what apps have which scopes, and a button to
revoke them.
Expiration after a certain time is possible, but hasn't yet been defined.
>
> What new requirements are imposed on an RP that are not already imposed by
> OAuth? It sounds like a ed25519 library, and potentially storing pub/priv
> keys? Are vetted ed25519 libraries readily available for popular languages?
>
>
That's it. Plus request signing instead of just passing a bearer token when
asking for information.
A thorough and popular library that includes the ed25519 library is
libsodium[1], which has bindings to many languages[2].
[1]: https://github.com/jedisct1/libsodium
[2]: http://doc.libsodium.org/bindings_for_other_languages/README.html
_______________________________________________
Dev-fxacct mailing list
[email protected]
https://mail.mozilla.org/listinfo/dev-fxacct
