[Openid-specs-mobile-profile] Account Migration - First Draft

Torsten.Lodderstedt at telekom.de Torsten.Lodderstedt at telekom.de
Fri Jun 10 11:01:17 UTC 2016


Hi Arne,

please find my comments below.

kind regards,
Torsten.

Von: Arne Georg Gleditsch [mailto:argggh at telenordigital.com]
Gesendet: Freitag, 10. Juni 2016 11:40
An: Manger, James
Cc: Lodderstedt, Torsten; openid-specs-mobile-profile at lists.openid.net; jbradley at mac.com; philippe.clement.ft at gmail.com; jbradley at me.com; vboyalakuntla at gsma.com
Betreff: Re: Account Migration - First Draft

Good to see the attention this is getting!  One aspect of the whole problem domain that I think we need to bear in mind is this:

The first RP to authenticate a user towards a new OP will cause the new OP to request issuance of proofs of migration for all RPs the old OP has issued sub values to for the given user, even if only one of these proofs is going to be presented to and be validated by one RP in the current transaction.
My proposal splits the process in two phases. Transfer of account data to the new OP is initiated by the user and performed ahead of logins at RPs.
The new OP must store all (the other) proofs in order to be able to present them to the remaining RPs as part of future authentications.
Certainly correct.
The lifetime of the proofs of migration must be specified, and the consequences for the end users when proofs are not validated before they expire must be clearly communicated.  If we mandate that all end users must ensure that they authenticate towards all the RPs where they want to maintain the association of their Mobile Connect login to the service profile within a given time frame after they trigger the issuance of proofs of migration, that needs to highlighted as well.
Among factors that may limit the lifetime of the migration proofs as drafted is at least (1) jwk key rollover,
rollover shouldn’t be a issue as it is supported by the underlying technologies (The spec therefore points out use of the kid element). The challenge I see is the limited lifetime of any assertion. I think several month should be enough and should work with key material with reasonable entropy. The completely different alternative would be to perform the authentication with the old during every migration of a local RP account. This requires means of authentication even if the user is no longer using the Mobile Connect service of the old OP.
(2) subsequent additional migration events,
How frequently might such migrations happen? Moreover, the basic assumption of the draft is to conduct the migration during login. So if the migration does not happen soon after the phone number porting, is the respective service really relevant for the user?
and (3) issuing OP going out of business.
Why? The user may trigger the data transfer directly after she has moved to the new OP.
Perhaps trying to address all of these amounts to letting perfect be the enemy of good, but on the other hand the currently outlined scheme, where the participating OPs agree to maintain a shared sub scope, is robust in face of all of these events.
Please explain why this proposal is robust? What I directly see is it puts additional burdens on implementers beyond the requirements of OpenID Connect.
In particular, if we want to maintain a signed migration path even if one if the OPs in the migration chain withdraws from the Mobile Connect ecosystem, or closes down altogether, I think it is unavoidable that we look towards a scheme where the proofs of migration are signed by a trusted third party, like the GSMA.
Interesting idea. Hopefully this 3rd party does not go out of business J
Regards,
Arne.

On Fri, Jun 10, 2016 at 5:50 AM, Manger, James <James.H.Manger at team.telstra.com<mailto:James.H.Manger at team.telstra.com>> wrote:
Thanks for writing down a concrete proposal, Torsten. http://lists.openid.net/pipermail/openid-specs-mobile-profile/Week-of-Mon-20160606/000439.html

Some comments:

The signed assertion by the old OP that the user has migrated to the new OP does not identify a specific account at the new OP. It lists the old 'sub', old 'iss' and new 'iss' (in 'migrated_to'). This means this assertion could be used with any account at the new OP, or even with multiple accounts at the new OP. An RP needs to trust the new OP so trusting them to only use the assertion with the correct account might be acceptable. However, it feels like a significantly bigger risk than alternative designs (eg where the 'sub' remains the same at old & new OP).

For instance, a "porting_data" value is likely to be sitting in the new OP’s database against a user’s account. If an attacker move the "porting_data" to their own entry in the new OP’s database, then they can take over the migrated user’s account at the RP. It’s an attack, but it might not be as hard as compromising an authentication flow.

This limitation might be able to be patched if the new 'sub' is also signed. That would require a more complex API: perhaps new OP gets list of 'sector_id's from old OP; then POSTs new 'sub's; which the old OP signs.



If we want to specify a general OP1→OP2 migration mechanism for any OIDC providers (not just Mobile Connect), then the doc would be much better removing all the MC, MNO, and phone number stuff.

In §2 "Overview" I would describe the first section as an API (instead of a protocol) offered by the old OP that is used by the new OP to obtain information about the account being migrated.

§3 "Migrating a User Account between Ops” explains discovery steps, multiple OAuth steps, and the API call all together. It would be clearer if we could specify the API and say it is OAuth-protected, leaving a full example flow using one example variety of OAuth to an appendix.

Pairwise 'sub' values are tied to a sector id (a domain name) — not a redirect_uri or sector_id_uri — so the response items should have a "sector_id", not either a "redirect_uri" or "sector_identifier_uri".
I guess "sector_id" should also be optional to support OPs that use public (non-pairwise) "sub"s.

The items returned by the old OP repeat the "sub" and "sector_id…" values: as direct JSON, and also in the "porting_data". That feels like poor design that just introduces the possibility of mismatches leading to security bugs.

The API response is an array of per-sector-id items. That leaves no room for any future extensions that apply to the whole account. It would probably be better as a top-level object with a "subs" element holding the array.
{
  "subs": [
    {"sub":…, "sector_id":… },
    {"sub":…, "sector_id":… }
  ]
}

The example signed porting data has an 'exp' (expiry) value that is 15 minutes after the issuing (porting) time. That will not work, given that an RP is expected to verify it, say, months in the future.

The example "porting_data" values are missing 'kid' (key id) values. They are very necessary in this case due to the long lifetime of the signatures (eg signed at porting time; verified by an RP on login perhaps months later).

The example "porting_data" values use symmetric MACs (HMAC), as opposed to asymmetric signatures (eg RSA). I doubt that can work.

The "porting_data" looks like an id_token from the old OP. In fact, it might even be accepted as an id_token by some RPs, which will silently ignore the "migrated_to" element as an unknown element for an id_token. Is that dangerous? I’m not sure; I’m not sure it isn't. We really need an element in the signed data to unambiguously identify the semantics of the message.

The old OP knows the new OP (hence the value to put in "migrated_to") based on the client_id of the new OP’s app that is calling the migration API.

"porting_data" in the id_token is a single JWT. Probably needs to be an array of JWTs as a user ports from OP1 to OP2 to OP3 (or back to OP1?). It is a bit of a corner case

"Host: discovery.example.com<http://discovery.example.com>" is used in one example [§3 step 4]. I suspect that should be "Host: op.mno1.com<http://op.mno1.com>", using the value from the "authorization_endpoint" from the previous step. Also change "GET connect…" to "GET /connect…" (add leading /).

The API call gets data for a specific account but uses a generic path "GET /connect/migrate", relying on the access_token to pick the right account. I’m not sure if this is the best way to design an API. The Mobile Connect migration spec adds the phone number in the path. Perhaps it isn't necessary, but it might help ensure each side is talking about the same user.

op1.example.net<http://op1.example.net> and op2.example.com<http://op2.example.com> might be better sample values than op.mno1.com<http://op.mno1.com> and op.mno2.com<http://op.mno2.com>.

I wonder what the best order of steps are for an RP in §4? After failing to find id_token.sub+iss in its DB, the RP might be better to look for id_token.porting_data.sub+iss in its DB before verifying the old OP’s sig, particularly if it involves calls to config and JWK URIs.

--
James Manger

-----Original Message-----
From: Openid-specs-mobile-profile [mailto:openid-specs-mobile-profile-bounces at lists.openid.net<mailto:openid-specs-mobile-profile-bounces at lists.openid.net>] On Behalf Of Torsten.Lodderstedt at telekom.de<mailto:Torsten.Lodderstedt at telekom.de>
Sent: Friday, 10 June 2016 9:01 AM
To: openid-specs-mobile-profile at lists.openid.net<mailto:openid-specs-mobile-profile at lists.openid.net>
Cc: jbradley at mac.com<mailto:jbradley at mac.com>; philippe.clement.ft at gmail.com<mailto:philippe.clement.ft at gmail.com>; jbradley at me.com<mailto:jbradley at me.com>; vboyalakuntla at gsma.com<mailto:vboyalakuntla at gsma.com>
Subject: [Openid-specs-mobile-profile] Account Migration - First Draft

Hi all,

please find attached the first draft of the Account Migration protocol. The design intentionally is kept generic so it can be used to migrate user accounts among any supporting OIDC OP.

Please review it and give me feedback.

thanks in advance,
Torsten.

PS: I'm currently having trouble to upload the HTML and xml source to bitbucket. I will upload it as soon as possible.

-----Ursprüngliche Nachricht-----
Von: Torsten Lodderstedt [mailto:torsten at lodderstedt.net<mailto:torsten at lodderstedt.net>]
Gesendet: Sonntag, 5. Juni 2016 13:43
An: John Bradley
Cc: Lodderstedt, Torsten; openid-specs-mobile-profile at lists.openid.net<mailto:openid-specs-mobile-profile at lists.openid.net>; philippe.clement.ft at gmail.com<mailto:philippe.clement.ft at gmail.com>; John Bradley; jbradley at mac.com<mailto:jbradley at mac.com>
Betreff: Re: [Openid-specs-mobile-profile] MODRNA WG Call June 1st 2016

Am 04.06.2016 um 14:17 schrieb John Bradley:
>
> We can.  I think the GSMA was going to discuss our feedback.
>

I will draft a first version.

> They had some other concerns with people doing multiple ports over a
> short period of time.  I don't know how much history is wort
> supporting vs increased complexity for the client
>
The easier approach is to ask the user to force migration at the RP by logging in after every port. Otherwise, this is ending up in signficant increased complexitity and potentially security holes.

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


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