[Openid-specs-mobile-profile] Account porting: draft -01: New OP encrypting port_token

Torsten Lodderstedt torsten at lodderstedt.net
Tue Sep 27 03:30:46 UTC 2016


Hi James,

the RP does not need to prove the sect

> Am 27.09.2016 um 04:41 schrieb Manger, James <James.H.Manger at team.telstra.com>:
> 
> > allowing the RPs to specify the sector id explicitly is a security risk
>  
> sector_id actually appears twice in a call to the port_check_endpoint: in the query parameter; and in the enc_port_token JWE header (where the New OP has bound it to the token by including it in the Additional Authenticated Data (AAD) of the AEAD encryption). Section 5 “Port checking API” should explicitly state that the Old OP MUST confirm that these two match.
>  
> Similarly the New OP is identified twice: in the iss query parameter; and by the client_id (in the “kid” member) in the JWE. Section 5 “Port checking API” should also explicitly state that the Old OP MUST confirm that these correspond to the same New OP.
>  
> The benefit of the duplication it that the Old OP sees the New OP’s view of {Old OP, New OP, RP} and the RP’s view of {Old OP, New OP, RP} and, hence, can ensure they match.
>  
> Is the security risk you see that the Old OP might use the query parameter values set by the RP without checking that match the values set by the New OP? Would explicit text saying these checks MUST be done addresses that sufficiently?
>  
> An alternative would be to drop the query parameters; add “iss” naming the New OP in the JWE header; and tell the RP to parse the JWE header to confirm the New OP and sector_id are as the RP expects. That eliminates some of the risk that the Old OP forgets a check (still needs to match New OP iss & client_id), but it feels like an even bigger risk that the RP forgets these checks. Parsing a JWE header without properly processing the whole JWE sounds particularly dangerous. I suspect it is bad if the RP blindly forwards an enc_port_token with no confirmation it is about itself and the New OP it got it from, though I haven’t worked out any actual attacks.
>  
>  
> Authenticating the RP in the Porting check API calls is possible. I was going to add it, but hadn’t worked out any specific attacks that is would prevent so I left it out. It does add the complexity of the RP obtaining a client_id/client_secret for the Old OP, which is non-trivial for the Mobile Connect case. Arne suggests using these credentials directly in the Porting check API (like they are used at the token endpoint), but it would probably be more architecturally correct to use normal OAuth 2.0 and get an access_token from /token for use at the port_check_endpoint (as is used at the user_info_endpoint). That is another request, and another scope value.
>  
> Open questions:
>  
> What are the security risks if the Old OP does not authenticate the RP?
>  
> What are the security risks if the RP’s view of the {New Op, sector_id} doesn’t match the enc_port_token values
>  
>  
> I’ll add explicit text stating the checks the Old OP MUST do.
>  
> --
> James Manger
>  
>  
>  
> From: Arne Georg Gleditsch [mailto:argggh at telenordigital.com] 
> Sent: Tuesday, 27 September 2016 3:18 AM
> To: Manger, James <James.H.Manger at team.telstra.com>
> Cc: openid-specs-mobile-profile at lists.openid.net
> Subject: Re: [Openid-specs-mobile-profile] Account porting: draft -01: New OP encrypting port_token
>  
> Hi James, group,
> 
> I think this proposal is starting to look really solid.  My reflections on the current version:
> 
>> Section 5. Porting check API:
> 
> I think allowing the RPs to specify the sector id explicitly is a security risk, and suggest that we mandate that RPs authenticate towards the Old OP using HTTP Basic Auth (in the same way as they would towards the token_endpoint), and that the Old OP resolves the sector id based on the authenticated client id.  Alternatively, we could mandate that the Old OP somehow verifies the given sector id towards the encrypted port_token, but that would introduce a coupling between the pairwise subject id algorithms of Old and New OP that I understood we wanted to avoid.
> 
> (For the Mobile Connect specific scenario, adding authentication to this invocation requires that the RPs are able to resolve their Operator Discovery-provided credentials towards the Old OP based solely on the iss value. I suggest that we presume that the Operator Discovery facility will be able to assist with this at some point in the future.  Should that turn out to not be possible, a fallback strategy could be to make the OPs include a member mc_od_identity in their configuration document, with values like e.g "https://discover.mobileconnect.io/telenor_group/v2/discovery?Redirect_URL=http://localhost/&Selected-MCC=242&Selected-MNC=01". Mobile Connect RPs could then invoke this endpoint using their Operator Discovery credentials to obtain credentials appropriate for use towards the Old OP's port_check endpoint.)
> 
> BR,
> 
> Arne.
>  
>  
> On Thu, Sep 22, 2016 at 10:30 AM, Manger, James <James.H.Manger at team.telstra.com> wrote:
> Attached is an updated draft of OpenID Connect Account Porting: draft-account-porting-01.
>  
> Or read it at https://id.cto.telstra.com/2016/openid/draft-account-porting.html
>  
> _______________________________________________
> 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/20160927/55dc3bca/attachment-0001.html>


More information about the Openid-specs-mobile-profile mailing list