[Openid-specs-mobile-profile] Alternative account porting design
Torsten Lodderstedt
torsten at lodderstedt.net
Thu Aug 25 16:31:03 UTC 2016
Hi Arne,
thanks for the explanation.
If I get it right, the current Mobile Connect credential mgmt regime
requires to map the "iss" provided in "aka" to "mnc" & "mcc" because
these data are needed to identify the MNO/OP?
best regards,
Torsten.
Am 25.08.2016 um 15:49 schrieb Arne Georg Gleditsch:
> Hi Torsten,
>
> I'm not opposed to the general approach of letting the old OP map to
> the correct sector id without requiring the new OP to supply all
> relevant pieces of information needed to do so. I am, however,
> apprehensive about formulating an approach that requires deployment
> and adoption of an entirely new operator discovery and client
> credentials framework in order to work.
>
> FWIW, all the RPs we've helped onboard obtain operator credentials
> through the operator discovery. Our OP platform also verifies client
> credentials using operator discovery's request validator facility.
>
> For the current credentials management regime, we need some way to get
> from the "aka" structure to (the credentials returned in) the json
> document returned from e.g
> https://discover.mobileconnect.io/telenor_group/v2/discovery?Redirect_URL=http://localhost/&Selected-MCC=242&Selected-MNC=01.
> It may be sufficient that we mandate that issuers must include a link
> like the one above under the key "mc_discovery_identity_endpoint" or
> similar in its openid-configuration document, for instance. (It would
> be nice if the URL was a little less clunky, but as long as it is
> opaque to the RP, I guess we can improve on that as needed. The
> important point would be that it is an endpoint that the RP can invoke
> with its operator discovery credentials to receive a document
> containing credentials appropriate for the old OP it is in the process
> of contacting.)
>
> I realize that this is quite Mobile Connect specific, and may be more
> relevant to a CPAS document rather than to a general spec. However,
> since this disconnect is introduced with the scheme now under
> discussion, I'd like the to request that the operators aiming to use
> this spec in a Mobile Connect context indicate if they'd support this
> approach of managing credentials for RPs using the current incarnation
> of operator discovery, or if there are other ways we could close this gap.
>
> Regards,
>
> Arne.
>
>
> On Thu, Aug 25, 2016 at 1:45 PM, Torsten Lodderstedt
> <torsten at lodderstedt.net <mailto:torsten at lodderstedt.net>> wrote:
>
> Hi Arne,
>
> I think we first of all should come up with a viable solution.
>
> My concern is if we depend the solution on a rather limited
> approach to RP identification. In my observation, using redirect
> URIs (or sector ids) for that purpose has the following issues:
> - it works for front channel OIDC only, where redirect URIs are
> part of the protocol. It won't work for any back channel OIDC
> - it assumes the RP's redirect URI is the same for old and new OP,
> which may directly contradict security mitigations for the mix-up
> attack. Based on the current discussions about this attack, I
> expect the community will advice implementors to use
> distinct/different redirect URIs for every OP/AS
> - redirect URIs using custom schemes or device local targets can
> be faked, which renders the mechanism useless for native apps
>
> On the other hand, using the RP's client credentials with the old
> OP is the natural way to identify/authenticate RPs in OIDC.
> - it works with any grant/response type and flow
> - all logic to determine the subject value for a RP is already in
> place at the old OP, they will just be reused for the migration
> use case
>
> Do we have real issues with the way operator discovery works
> today? I don't know. According to my information, most active
> deployments use manually configured client credentials. My
> proposal would work in these deployments right away. If other
> deployments want to offer account migration, either API exchange
> will need to offer a way to directly obtain client credentials or
> those deployment are being migrated towards dynamic client
> registration (which is on the roadmap anyway). I think that's an
> acceptable price for having a secure and privacy-preserving
> account migration solution.
>
> I agree with you, account migration is a strongly desired feature,
> but we should take the time to come up with a really robust and
> secure solution. In my opinion, account migration is the most
> security-critical function in Mobile Connect. If we don't to it
> right in our first attept, it will allow attackers to conveniently
> hijack accounts using an interoperable API. That really scares me!
>
> best regards,
> Torsten.
>
> Am 24.08.2016 um 15:39 schrieb Arne Georg Gleditsch:
>> Hi Torsten,
>>
>> I welcome an overhaul of the discovery process, but it concerns
>> me if we make that a prerequisite of getting a viable solution to
>> life cycle handling in place. I think this is overdue as it is,
>> I'd be much happier if we could design a scheme that worked with
>> both variants of operator discovery.
>>
>> Regards,
>>
>> Arne.
>>
>>
>>
>>
>> On Wed, Aug 24, 2016 at 10:38 AM, torsten at lodderstedt.net
>> <mailto:torsten at lodderstedt.net> <torsten at lodderstedt.net
>> <mailto:torsten at lodderstedt.net>> wrote:
>>
>> Hi Arne,
>>
>> I hope Mobile Connect discovery and credential management
>> will be decoupled and aligned with OpenId/OAuth standard
>> mechanisms. We had productive discussions about that topic
>> with GSMA and will see first results with the intro of the
>> openid-configuration to API exchange soon. Next step might be
>> use of Software Statements for credential mgmt.
>>
>> I recommend you to take a look onto MODRNA discovery and
>> registration drafts in our repo.
>>
>> In this case, RPs will have/manage their OP credentials
>> independent of the discovery process. So it should be
>> possible to authenticate towards the old OP.
>>
>> best regards,
>> Torsten.
>>
>> Sent by MailWise <http://www.mail-wise.com/installation/2> –
>> See your emails as clean, short chats.
>>
>>
>>
>> -------- Originalnachricht --------
>> Betreff: Re: [Openid-specs-mobile-profile] Alternative
>> account porting design
>> Von: Arne Georg Gleditsch <argggh at telenordigital.com
>> <mailto:argggh at telenordigital.com>>
>> An: Torsten Lodderstedt <torsten at lodderstedt.net
>> <mailto:torsten at lodderstedt.net>>
>> Cc: "Manger, James" <James.H.Manger at team.telstra.com
>> <mailto:James.H.Manger at team.telstra.com>>,openid-specs-mobile- <mailto:openid-specs-mobile-profile at lists.openid.net>profile at lists.openid.net
>> <mailto:profile at lists.openid.net>
>>
>> Torsten Lodderstedt <torsten at lodderstedt.net
>> <mailto:torsten at lodderstedt.net>> writes:
>> > 3) RP sends request to porting check API at the old OP,
>> including the
>> > porting token + the credentials it regularily uses to
>> > identify/authenticate with the tokens endpoint of this
>> particular OP
>> > (it must have an identity with this OP as it is a RP for
>> this OP as
>> > well)
>>
>> I agree that complete separation of RP identification is a
>> nice feature
>> -- however, we need to keep in mind that in a Mobile Connect
>> context,
>> the RPs cannot be expected to hold on to (up-to-date)
>> credentials for
>> all OPs, not even the ones they have previously been in
>> communication
>> with. For them to to be able to authenticate towards the old
>> OP, they
>> would need to first communicate with the Operator Discovery
>> facility to
>> retrieve OP-specific credentials. This is not a show-stopper
>> per se,
>> but it is going to complicate the flow a bit for the RPs. We
>> also need
>> to supply them with information they can use towards Operator
>> Discovery
>> to resolve the old OP, i.e just indicating the old iss value
>> is not
>> going to be enough at this step. (Although it would be nice
>> if OD
>> supported lookups by iss...)
>>
>> --
>>
>> Arne.
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-mobile-profile/attachments/20160825/1928bcd0/attachment-0001.html>
More information about the Openid-specs-mobile-profile
mailing list