[Openid-specs-mobile-profile] Moderna Feedback from T-Mobile: AKA for porting

Manger, James James.H.Manger at team.telstra.com
Wed Jul 18 02:19:04 UTC 2018


Hi Michael,

The current account porting spec involves a single port token, not a port token per RP. The port token itself is not RP-specific. When the New OP uses authenticated encryption to include the port token in an id-token for a specific RP, the RP's sector_id is part of the authenticated data. That binds the port token to the RP-specific detail necessary for the Old OP to know the correct pairwise subject id (sub) to return (the RP is also authenticated when calling the Old OP).

More comments inline.

--
James Manger

From: Engan, Michael [mailto:Michael.Engan1 at T-Mobile.com]
Sent: Wednesday, 18 July 2018 3:39 AM
To: Manger, James <James.H.Manger at team.telstra.com>; Openid-specs-mobile-profile <openid-specs-mobile-profile at lists.openid.net>
Cc: Latham, James <James.Latham5 at T-Mobile.com>
Subject: RE: Moderna Feedback from T-Mobile: AKA for porting

Good morning, Sorry for my delayed response, I was out on vacation.

I have added some comments inline with yours with my initials [me]

From: Manger, James [mailto:James.H.Manger at team.telstra.com]
Sent: Tuesday, July 10, 2018 7:54 AM
To: Engan, Michael <Michael.Engan1 at T-Mobile.com>; Openid-specs-mobile-profile <openid-specs-mobile-profile at lists.openid.net>
Subject: RE: Moderna Feedback from T-Mobile: AKA for porting

Hi Michael,

"The assertion from the old MNO" actually needs to be many assertions - one per RP - since it carries "the old MNO's pairwise subject" (ie a RP-specific "sub").
So if a user has accessed 100 RPs, then during porting the old MNO need to generate, sign and send 100 JWTs, and the new MNO need to store these. Would we need limits?

[me] this is already the case. If the user ports under the current moderna suggestion, then the old mno needs to generate a PORT token. In order for that PORT token to return the correct pairwise subject identified the old MNO needs to track which RP it was issued to, and therefore issue a different PORT token for each RP the user already visited. Likewise this means the New MNO also has to know which previous RP's the user had approved (we want this anyways so the consents port), and store an AKA value to use for each.  So the suggestion to make the PORT token a JWT does not shift the underlying needs there to track per RP.    NOTE: all this would be easier IF the MNO's don't use pairwise Subject identifiers. In which case a single AKA value for OLD sub would work. (still signed by some method).  But our business teams have reiterated that they want MNO's to use pairwise identifiers for each sector_url.

[james] This is not how the current spec works, where a port token is not RP-specific. See above.

[james] Transferring consents is not part of the current spec. That would require extra data in a porting exchange, probably per-RP (unless there was a fancy probabilistic approach with, say, a bloom filter).

An old MNO might not know all the RPs a user has visited. It isn't strictly necessary to record this if the per-RP pairwise sub is derived whenever a login to that RP occurs. That would make it basically impossible to generate all the assertions at the porting time.

[me] the old MNO must capture consents. Even if the MNO generates the pairwise subject identifier with each login, the MNO has to still have a record to confirm if the user has already granted this RP access to the requested scopes. Otherwise the user will be asked with every login/access  ... "user do you agree this RP can access your xxx".          Note: to support porting I know T-Mobile will need to convert our realtime generation of the pairwise subject. But this is needed because we will also now need to support a pairwise subject login Hint. We don't want RP's using the phone number so if the RP is told to use the subject as the reference. Then the RP needs to be able to use the subject as the login hint, and therefore We have to have a recorded version of each pairwise subject so we can lookup which internal user it is referencing.

[james] It does seem likely that most IdPs will keep per-user-per-RP details. So perhaps we could bake that assumption into a porting spec. But it is far from clear to me that such a restriction plus its implications for needing to calculate/transfer/reveal/store lots more data is a good trade-off to avoid an extra RP-to-Old-OP call.

Another disadvantage of generating all the per-RP assertions up front (at port time) is the privacy issue. The new MNO learns the user's entire history, even if the user never intends to visit some of the old RPs ever again.

[me]  ok, yes I agree.. but this is  1) a biz call.. when a user ports a phone number from one carrier to another carrier will the user be able to Port their identity..  (when mno's use pairwise that means porting all your RP's, consents you granted each, and the subject/token/porttoken you were known as for that RP.       2)  this is also user controlled.   When a new MNO wants to pull/port you they will make an authentication request to the old MNO with the "Port_data" scope. This means the User can be shown and explicitly consent to the porting of all their data from the old carrier to the new carrier.  If the user chooses they can decline consent for the port_data scope, while approving other scopes like "profile". This would let a user simplify onboarding to the new MNO, but RP's will see a new Subject. (possibly with existing attributes like phone number, and email).  This may cause security problems where we tell RP's to use the subject as the reference, and the other fields as simple data attributes.

[james] A biz call indeed. Though a New OP only learning the RPs you use when (and if) you login to those RPs via the New OP seems like a much more privacy-friendly default behaviour.

Assertions that are generated at port time, but not consumed by an RP until the user next signs in to that RP (perhaps months later), means we need longer-term keys and revocation support. In contrast to the current scheme that can operate with frequently-rotated short-term no-revocation-needed keys.

[me]  correct. Totally agree. Which is why I suggest that an MNO generate two key pairs. One for JWT -> ID_Tokens which can be rotated frequently.  And then a second Key pair JUST for signing/encrypting the PORT token(jwt/jwe)  which would rotate slowly.   It could be possible that the old MNO still allows an interface that a RP could use for Port token validation in the event the port token siging key has rotated out of the jwks file. (in which case the old mno needs to keep it internally listed for longer).    But even if  we don't make the port_token a JWT, the old MNO still needs to keep in memory for a long period the method of validating that token and the data it represents, which is still the same challenge.

[james] 3rd parties (RPs) being able to verify long-term tokens is not really the same challenge as being able to verify your own tokens. The former needs a public revocation infrastructure (and relies on the 3rd parties actually checking for revocations, which has been notoriously poorly implemented in web PKI in practice). The latter just needs a local process.

[james] A 2nd key pair is an extra complexity. Plus the OpenID Connect mechanism of publishing a JWK key set doesn't have a clean way of marking 1 key for id-tokens and a separate key for port tokens. Publish both keys and RPs will accept id-tokens and port tokens signed by either, which seems to undermine the use of short-term keys.

--
James Manger

From: Openid-specs-mobile-profile [mailto:openid-specs-mobile-profile-bounces at lists.openid.net] On Behalf Of Engan, Michael
Sent: Tuesday, 3 July 2018 8:52 AM
To: Openid-specs-mobile-profile <openid-specs-mobile-profile at lists.openid.net<mailto:openid-specs-mobile-profile at lists.openid.net>>
Subject: [Openid-specs-mobile-profile] Moderna Feedback from T-Mobile

Good Morning, I would like to offer up some feedback conversations to the working group on the following:

...

1)      AKA for Porting
The US carriers have been discussing the AKA parameter for account porting. Ideally an ID_Token can be validated by an RP with only a cached public key for the carrier. Under the current suggestions the RP would now need to make a request to the original carrier with any port_token to complete the validation.  To go back to completely validated by the RP, we would like to see the AKA port token be something like a JWT, or JWE from the original carrier. This way the RP can validate the id_token, and the port_token with cached jwk public keys from both the new and original MNO.
The assertion from the old MNO needs to carry at least

  *   Acknowledgment from the old mno that the user has ported Out of the old MNO
  *   Acknowledgement from the old mno that the user has ported TO the new mno.
  *   Confirmation what the old MNO's pairwise subject was.
  *   Possibly a date of the PORT for use in anti-fraud detection.
It will remain up to the RP to update their subject from the old mno Sub to the new mno's sub once AKA port_token validation is complete.




Michael Engan
Principal Systems Architect,
Authentication, Authorization, & API security
12920 SE 38th Street | Bellevue, WA 98006
Direct 425-383-2268 | Mobile 425-443-3463

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


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