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

[Arne Georg Gleditsch]

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
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/a7e57b8e/attachment-0001.html>