[Openid-specs-mobile-profile] Account porting: how to encrypt

[Torsten Lodderstedt]

what if the OPs use public key crypto/assertions instead of client secrets for authentication? 

> Am 21.09.2016 um 02:52 schrieb Manger, James <James.H.Manger at team.telstra.com>:
> 
> We shouldn’t need another secret.
>  
> I had forgotten about OIDC Core §10 “Signatures and Encryption” where use of client_secret (after hashing and truncating) as an encryption key is explicitly defined. That removes the downside mentioned earlier for option 2. Option 2 would reveal the New OP’s client_id (issued by Old OP) to all the RPs, but that shouldn’t be an issue.
>  
> Reusing (the truncated hash of) client_secret to encrypt porting messages, in addition to encrypting and decrypting other OIDC messages (id_token, UserInfo response, requests, client auth) would be fine if only JWT had a proper way to unambiguously define the semantics of a message!
>  
> How about option 2 with "iss":new_op, "sector_id", "cty":"oidc-porting", and "kid":client_id in a JWE header and a string from the Old OP ("port_token_plain" value) as the payload?
>  
> --
> James Manger
>  
>  
> From: Torsten.Lodderstedt at telekom.de [mailto:Torsten.Lodderstedt at telekom.de] 
> Sent: Wednesday, 21 September 2016 1:25 AM
> To: Manger, James <James.H.Manger at team.telstra.com>
> Cc: openid-specs-mobile-profile at lists.openid.net
> Subject: AW: Account porting: how to encrypt
>  
> Hi James,
>  
> do you think this function is worth managing another secret? What about using the new OP’s private key to additionally sign the package containing the porting token?
>  
> best regards,
> Torsten.
>  
> Von: Openid-specs-mobile-profile [mailto:openid-specs-mobile-profile-bounces at lists.openid.net] Im Auftrag von Manger, James
> Gesendet: Dienstag, 20. September 2016 06:27
> An: openid-specs-mobile-profile at lists.openid.net
> Betreff: [Openid-specs-mobile-profile] Account porting: how to encrypt
>  
> The current idea for account porting is for the Old OP to provide a single token (which I’ll call port_token_plain) to the New OP; the New OP encrypts it (for the Old OP) before passing the ciphertext (port_token) to an RP; the RP passes it onto the Old OP; the Old OP decrypts it to retrieve the original token and returns the RP-specific subscriber id to the RP.
>  
> The per-RP (actually per-sector-id) encryption is necessary to preserve the privacy of pairwise subs.
>  
> An open question is how to do the encryption.
>  
> Option 1: public key and algorithm from Old OP metadata.
> The port_token seen by an RP could be a JWE (compact encoding?).
> One downside is that the encryption does not authenticate that is was done by the New OP.
>  
>  
> Option 2: symmetric encryption with secret shared by the New OP and Old OP (such as the New OP’s client_secret used in calls to Old OP).
> The port_token seen by an RP would be the ciphertext from an AEAD algorithm, keyed with the client_secret, using the iss and sector_id in the additional authenticated data.
> This approach saves a few bytes, avoids some public key crypto, and avoids a metadata lookup to get a public key. A downside is that client_secret is not designed to be used as an AEAD secret key.
>  
> Any preferences?
>  
> --
> James Manger
>  
> _______________________________________________
> Openid-specs-mobile-profile mailing list
> Openid-specs-mobile-profile at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-mobile-profile
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-mobile-profile/attachments/20160921/a82d2f19/attachment-0001.html>