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

[Manger, James]

sector_id is mandated by OpenID Connect as the one-and-only mechanism to partition pairwise Subject Ids (subs), other than public subs. There shouldn’t be any problem exposing this to RPs. RPs really should be aware of pairwise partitioning as it is likely to be really important to any future changes they make to the sets of apps and services they want to offer.

I guess an OP that only issues public subs might not bother determining an RP’s sector_id so it would be awkward to include it in enc_port_token. And hence awkward for the Old OP to rely on it to avoid needing to authenticate the RP.

Arne & Torsten have almost swayed me to authenticating the RP to the Old OP.

It offers the (slight?) privacy advantage of the New OP not being able to get old pairwise subs for a porting user.
It doesn’t necessarily add any extra requests if an RP often calls Old OP (so has credentials, access_tokens etc). Though it might add a couple of extra requests if the RP need to get Old OP creds from a discovery service, then swap them for an access_token, before calling the API.
The RP and Old OP not being able to confirm enc_port_token was created for this RP is probably not a risk as long as the New OP is authenticated.

I think we still need the Old OP to check that who the RP thinks the New OP is does match the party that encrypted enc_port_token; hence we still need the iss=New_OP query param of the Porting check API.

--
James Manger


From: Arne Georg Gleditsch [mailto:argggh at telenordigital.com]
Sent: Tuesday, 27 September 2016 2:07 PM
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,

On Tue, Sep 27, 2016 at 4:41 AM, Manger, James <James.H.Manger at team.telstra.com<mailto:James.H.Manger at team.telstra.com>> wrote:
> 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?

Yes, unless this is mandated I am concerned that malicious RPs could use the port_check endpoint to discover the sub values provided to other RPs by the Old OP.  However, as Torsten says, mandating this check introduces a tight coupling between how the Old and New OP partition their pairwise subject ids, and also to a certain extent exposes the mechanics of the the pairwise subject id partitioning to the RP.  I would prefer if the sector id was calculated independently by the Old and New OP, derived from the RP's client entry with the individual OPs.  In fact, I would suggest making the sector id that is included in the AAD opaque to the Old OP by hashing it.

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.

I'm not sure I see the need for that, to be honest.  If we are going that route, we should probably go all out and use a regular OIDC flow, passing the enc_port_token as a variant of id_token_hint or similar, and present the port_check data in the resulting id_token.  This is certainly a possibility, although I haven't considered all the implications.  It would allow Old OPs to obtain end user consent on a RP-to-RP basis for porting history, if they should so desire, so perhaps it is something we want to consider?  It's going to make the flow for the RP even more complicated, though.
BR,
Arne.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-mobile-profile/attachments/20160927/be8f065d/attachment.html>