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

Arne Georg Gleditsch argggh at telenordigital.com
Tue Sep 27 04:06:44 UTC 2016

Hi James,

On Tue, Sep 27, 2016 at 4:41 AM, Manger, James <
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

> 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,


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-mobile-profile/attachments/20160927/a7e57b8e/attachment-0001.html>

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