[Openid-specs-mobile-profile] New Version of Account Migration Draft

[Arne Georg Gleditsch]

Some introductory remarks: The concerns I have must be seen in light of
the fact that we are discarding some properties of the earlier scheme
that was discussed in the Mobile Connect context that may have had
value.  As you know, the previous scheme considered all issuers
participating in the Mobile Connect federation as the same security
domain, and considered transfer of the pairwise subject ids as the proof
of migration.  This meant that the RP did not need to consider the path
of migration, and that the proofs of migration were guaranteed to not
expire.

The scheme currently under discussion inarguably is more general and has
more robust security properties. but I would like us to explicitly
consider if (1) the attractive properties present in the first scheme
can be somehow fit into this new one, and if so (2) if the complexity is
worth it, or (3) if the consequences of losing those properties are
acceptable.

<Torsten.Lodderstedt at telekom.de> writes:
>> 1) The draft explicitly states that chained migration is out of scope.  However, as far as I read the current draft, if we just allow the from
>> clause of a migration_data claim to itself contain a nested migration_data claim, we would have it for free.
>
> I personally do not believe anything in life comes for free ;-) My intention is to keep the complexity of this draft on a reasonable level.
> And I do not see the need for chained migration (yet).
>
> Having said that, I’m open for your proposal. Please propose text, we could add to the draft describing the formats and processing
> rules for nested migration data. I think we also need to keep an eye on potential additional security threats. Such a proposal would
> serve as a base for detailed discussion in the WG.

I would add/change the following text in section 4:

  The RP is supposed to act as follows:

  If the RP does not find an user account within its database using the
  combination of the iss and sub claim, it checks whether there exists a
  migration_data claim in the id token. If that's the case the OP
  inspects the migration data and attempts to migrate the user account
  identified by the migration data JWT within its database to the values
  asserted by the id token. The migration_data claim may itself contain
  a further migration_data claim if the account was migrated more than
  once. The RP inspects the chain of migration data proofs until it
  finds a known iss and sub claim combination, or the chain is
  exhausted. 

  In the example case, the id token carries a migration_data claim,
  which contains the following JWT:

  [..]

  1. The RP first MUST validate the digital signature of the migration
  data JWT. It therefore looks up the old OP's openid configuration as
  defined in [OpenID.Discovery] using the "iss" sub claim of the claim
  "from" and uses it to obtain the location of the old OP's JSON Web Key
  Set [RFC7517]) (containing the respective public keys of the OP).

  2. If the signature has been validated successfully, the RP checks
  that the migration_data was legitimately transferred to the party
  presenting it. It does this by verifying that the "to/iss" claim of
  the migration data contains a value matching the issuer of the token
  that the migration data was included in. If the migration data
  currently being verified was included as direct claim in the id token
  of the actual authentication response, this is the "iss" claim of that
  token; if it was included as a "from/migration_data" claim of another
  migration data token, it is the "from/iss" claim of that token.

  3. If this check was successful, the RP checks whether it can find an
  existing user account in its database using the combination of
  "from/iss" and "from/sub" obtained from the migration data JWT. In the
  case of the example above, this would be the the issuer
  "https://op.mno1.com" and the sub "45445454".

  4. If there is a match, the RP changes the corresponding database
  values to the values of the claims iss and sub of the actual id
  token. In the example, the respective values would be
  "https://op.mno2.com" and "676887676767".

  5. If no match was found, the RP examines the migration data JWT for
  an encapsulated "from/migration_data" claim.  If this exists, the RP
  repeats the process above from step 1, starting by validating the
  signature of the encapsulated migration data JWT.

  6. After this process has terminated, the account of the actual user
  has effectively been migrated to the new OP. If the same user logs
  into the same RP again, the RP would not consider the migration data
  again because it would successfully lookup the local user account
  using the iss and sub provided by the new OP.


>> 2) We are inflating the size of the id_token a bit.  What if we instead of (or as an alternative to) the migration_data claim had a
>> migration_data_url claim, indicating an endpoint that could be accessed to obtain the actual migration data payload?  (This endpoint
>> should be accessed with authorization bearer carrying the user's access token.)
>
> Interesting idea – But I’m worried about the fact the old OP would need to maintain a database of _all_ issued migration JWTs (the
> respective data and id to be more precisely). Moreover, login to the RP would take longer due to the additional network roundtrip
> between RP and old OP. Sounds like a trade of message size for backend state and latency. Do you really think the saved message
> size is worth this change? We are talking about a couple of hundred bytes. 
>
> On the other hand, if we change the design that way, we also need to investigate the impact on security. In the current model, the new
> OP can verify the migration data content and attest it to the RP along with its own user data. This is no longer possible with your
> proposal.
>
> Regarding authz of the request to the old OP: Using access tokens would mean the RP needs to obtain an access token with the old
> OP, right? How would you imagine this to work? I would rather propose to put the identifier of the migration data JWT in the URL the old
> OP issues to the new OP (making it a URL pointing to a particular migration data resource).

I'm sorry, that was probably unclear: I was not suggesting that the old
OP maintain this, rather that the new OP could use this as an alternate
means of communicating the migration_data payload to the RP.  Latency
shouldn't be much of an issue, as RPs would only need to fetch the
actual migration data once per migration.  This is probably more
relevant if we decide to allow chaining, though.

>> 3) Regarding time-to-live of migration proofs and the required verification key material: I think it would be wise if we gave some thought
>> to how we want to enable RPs to verify migration proofs even if the original OP is unavailable/has retired the required key material. 
>> Could we perhaps allow migration_data to have the alternate form
>>
>> {
>>   "notarized": {
>>
>>     "iss": "https://ttp.com",
>>
>>     "iat": 1468925762986,
>>
>>     "migration_data": "ey..."
>>   }
>> }
>>
>>  
>>
>> With the semantics that the signature protecting the encapsulated migration_data JWT was verified to the issuer's satisfaction at the
>> given time?  This presupposes a service at the TTP that could verify a JWT signature and produce a notarized encapsulating JWT, and
>> that the TTP pledged to keep verification key material accessible for a significant amount of time.  The RP could then, provided they
>> recognize the issuer of the notarized claim as a trusted third party, use the payload section of the encapsulated JWT without
>> themselves verifying the signature.  (RPs not happy with deferring signature verification can choose to ignore the notarized wrapper
>> and verify the original signature themselves, accepting the life cycle risks of OPs and JWT verification key material.)
>
> Looks like the introduction of a CA concept in the JWT space, which would make the spec significantly more complex. As I stated
> above, I want to keep the spec as simple as possible. How relevant is the use case in your opinion? I would be satisfied if we could
> support migration of user accounts in the general case (to start with). If an OP goes out of business (suddenly), no one could even
> start a regular migration process. I would rather assume that the user will need to reestablish access to its RPs using RP-specific
> recovery methods (or using alternative authentication methods at the RP).

This is getting quite far into corner case territory, but it is
conceivable that an OP goes out of business after a user has migrated
but before the transferred migration_data proofs have been presented to
all the user's RPs.

> Some detailed questions/remarks:
>
> - How is the RP supposed to determine whether the old OP is still in business (and able to provide the key material) or not?

If the RP trusts the indicated third party, I guess it would be natural
for them to verify the proof using the notarized signature every time,
since that would make key caching more efficient.  If they do not, they
can just ignore the notarization wrapper and the behaviour if the OP
disappearsh or retires the relevant key would be the same as currently
specified.

> - Expiration of key material is a different use case (in my opinion). I think the whole migration process could/should be conducted again
> in this case.

Agreed, there are different implications of an OP disappearing and an OP
rotating the keys in their JWK key set.  However, for an RP the result
is more or less the same: they are presented with migration proofs that
are no longer verifiable.

The keys used for signing JWTs here are obtained via the OpenID Connect
Discovery process, and the JWK spec explicitly states that the kid
parameter "is used, for instance, to choose among a set of keys within a
JWK Set during key rollover".  It is not unreasonable to expect at least
some operators to actively use this facility to regularly rotate their
keys.  (I know Google does.)  Currently, OpenID Connect providers need
to maintain signing keys for as long as it is reasonable to expect it to
take RPs to verify ID tokens, more or less.  The possible delay between
the signing and verifcation of our migration JWTs is magnitudes
different, and I think we need to address somehow how we consolidate
these two needs.  At the very least, we need to flag very clearly that
the implication of adopting this spec is that OPs need to use dedicated,
long-lived kids for the signing of migration proofs, or they must add a
grace period to their JWK set rotation schedule matching the time they
want their issued migration proofs to live.

That ended up being a lot of text.  Sorry I couldn't make it shorter...

Regards,

							Arne.