[Openid-specs-mobile-profile] How to generate the "sub" in Mobile Connect

John Bradley ve7jtb at ve7jtb.com
Tue Apr 21 19:10:20 UTC 2015


I would rather describe it as a porting identifier rather than a different subject, otherwise SP will tend to treat it as the subject.

All accounts would have the “ported_id".  

The SP gets the new authentication can’t find a iss/sub and checks the ported_id, if it matches an account it makes an OAuth API call to the old Iss with it’s client_id and the ported_out value and receives back the value for the new “iss”.   (to support mobile clients this would be public, but there is no PII to leak)

If the iss in the new assertion matches the response from the old iss then the account can be bound to the new Issuer.

This would be a bit similar to how the openID 2 to Connect migration works.

The downside is that this requires another indexed key for every account. (Though you might be able to optimize it if you have a separate table for ported out accounts.)

This could also be generalized for migrating accounts between any IdP.

The donor IdP needs to keep the porting info around for some time but that prevents people from hijacking accounts that are not ported.
IdP would need to show users there account_id and iss to give to the new IdP and allow them to set a value for the new_iss.  

I would rather develop a general account portability method that doesn’t rely on special mobile Connect logic, or trusted central authority.

John B.



> On Apr 21, 2015, at 3:21 PM, GONZALO FERNANDEZ RODRIGUEZ <gonzalo.fernandezrodriguez at telefonica.com> wrote:
> 
> Hi John,
> 
> Thank you for your precie response. I forgot that Jorg proposed to use an additional sub only for mobile connect, "mobile_connect_sub" that could be very usefule to resolve this problem.
> 
> Best,
> Gonza.
> 
> De: John Bradley <ve7jtb at ve7jtb.com <mailto:ve7jtb at ve7jtb.com>>
> Fecha: martes 21 de abril de 2015 19:39
> Para: Gonzalo Fernandez Rodriguez <gonzalo.fernandezrodriguez at telefonica.com <mailto:gonzalo.fernandezrodriguez at telefonica.com>>
> CC: "openid-specs-mobile-profile at lists.openid.net <mailto:openid-specs-mobile-profile at lists.openid.net>" <openid-specs-mobile-profile at lists.openid.net <mailto:openid-specs-mobile-profile at lists.openid.net>>
> Asunto: Re: [Openid-specs-mobile-profile] How to generate the "sub" in Mobile Connect
> 
> This would require that RP not consider the issuer part of the identifier.
> 
> That has significant security implications.   
> 
> Nothing stops a non MNO openID connect provider from producing a colliding PCR.  
> 
> The SP would be required to special case all there security logic for Mobile Profile operators,  and know who the operators are.
> 
> This would allow any operator to compromise the security of any other operators accounts.    Probably a non starter for something claiming to be secure.
> 
> The WG discussed this and decided that portability of the identity would be out of scope.   
> We can have a mechanism to allow users to migrate from one PCR/issuer to another, but even that is complicated if we want to prevent correlation.
> One way to do that would be to have globally unique PCR and when a SP receives a unknown iss/sub pair it would look to see if the sub exists for a registered account and if it is found,  then make a API call to the old issuer to see if the new issuer is now authoritative for that,  and if it is update the account record with the new issuer.
> 
> That is the only safe way to do something like this.  That prevents the donor operator from having there security arbitrarily compromised by any other operator.
> 
> It also stops people from crating SP software that ignores issuers, and causes general security problems with non MNO IDP.
> 
> It also allows MNO with existing SP’s and subject identifiers to be able to continue using them.
> 
> PS you should not use the client_id when generating the PCR, that will change over time and cause untold havoc.
> 
> The Connect spec has a way to generate a Pairwise identifier for a user. We should stick to that.
> 
> John B.
> 
> 
>> On Apr 21, 2015, at 1:11 PM, GONZALO FERNANDEZ RODRIGUEZ <gonzalo.fernandezrodriguez at telefonica.com <mailto:gonzalo.fernandezrodriguez at telefonica.com>> wrote:
>> 
>> Hi Guys,
>> 
>> I will not be able to attend to our call tomorrow, however I would like to add this topic to the tomorrow's call in order to be discussed (Jorg is aware of it, because it is an action point from our calls in the GSMA Working Group).
>> 
>> As all we know, the MSISDN is something susceptible to be ported from an operator to another, and this can have a big impact in the Service Providers that already have a "sub" to recognise the owner of this MSISDN.
>> In the GSMA Working Group we are talking about the need to migrate the sub (aka PCR: Pseudonymous Customer Reference) in case of portability. To do that, we need that the PCR is not tied to the MSISDN but to a Mobile Connect identifier that must be unique across all the operators. 
>> 
>> As per the OpenID Connect spec, the Service Providers should check the pair iss+sub to identify the users, however this wouldn't be possible in Mobile Connect, because we aim to identify the same user irrrespective of which is the current Identity Provider which the user belongs to. The conclusion is that we need to generates PCR with the follow constraints:
>> 
>> The PCR must be unique across all the operators.
>> The PCR should be created only once per MSISDN and to maintain it all the portabilities long.
>> To achieve that, one possibility could be to have a central database, however this could be a poor solution due to scalability and additional integrations between the OIDC providers and this common database.
>> Another possibility could be that PCR's are created by the MNO where the user is registered in the Mobile Connect for the first time. As this solution implies to create the PCR in a distributed way, it need to agree how to do it in order to avoid collisions, so we have proposed the next mechanism to create this PCR's:
>> Generate a PCR like: Hash(iss+client_id+user_id)
>> The user_id would be up to each operator
>> The client_id (Service Provider identifier) should be agreed among all the operators, because it would be necessary when the user is ported to know which PCR is related with which Service Provider.
>> The iss avoid collisions among operators
>> The Hash is something to obfuscate
>> This PCR should be deleted in the event that the MSISDN is recycled.
>> 
>> It would be very useful to have comments on this working group, so I would encourage you to discuss this topic to give feedback to the GSMA WG.
>> 
>> Thanks in advance, and sorry to not be able to attend the call tomorrow.
>> Gonza.
>> 
>> 
>> Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener información privilegiada o confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la lectura, utilización, divulgación y/o copia sin autorización puede estar prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción.
>> 
>> The information contained in this transmission is privileged and confidential information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, do not read it. Please immediately reply to the sender that you have received this communication in error and then delete it.
>> 
>> Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destruição
>> _______________________________________________
>> Openid-specs-mobile-profile mailing list
>> Openid-specs-mobile-profile at lists.openid.net <mailto:Openid-specs-mobile-profile at lists.openid.net>
>> http://lists.openid.net/mailman/listinfo/openid-specs-mobile-profile <http://lists.openid.net/mailman/listinfo/openid-specs-mobile-profile>
> 
> 
> 
> Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener información privilegiada o confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la lectura, utilización, divulgación y/o copia sin autorización puede estar prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción.
> 
> The information contained in this transmission is privileged and confidential information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, do not read it. Please immediately reply to the sender that you have received this communication in error and then delete it.
> 
> Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destruição

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-mobile-profile/attachments/20150421/53d9d2a5/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4326 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-mobile-profile/attachments/20150421/53d9d2a5/attachment-0001.p7s>


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