W3C

Authentication by Communication Network

17 Sep 2019

Attendees

Present
weiler, Chunming, James_Barclay, david_singer, Jia_Qiang, Chen_jun, and_more...
Regrets

Chair
Jia_Qiang
Scribe
weiler

Contents


<scribe: Chunming>

Meeting: Authentication by Communication Network

[Summary: Introduce what Telecom Authentication is, and introduce the security risks and solutions of Telecom Authentication, especially when using WEB, instead of client, to authenticate.]
https://w3c.github.io/tpac-breakouts/sessions.html#telecom-authn

Jiaqiang:introduce myself, I am from the China Mobile security team, with my college chenjun
... we come from operators

[slide: background: "mobile number is userID in most APPs"]
... telecom authentication: the mobile phone number is the userID in most APIs in china.

Gerhard: phone is not used for login, but when strong auth - 2FA - is needed, phone number is used as "thing you have", so this will let us get rid of SMS-OTP and prevent SIM-swap fraud.
... interested to see a std soln. this is still useful.

[slide: problem solved: hard user acquisition caused by complex registration, 2) mgmt burden from multiple mlogin methods 3) security risks of pw dilvuge]

Jiaqiang:we want to deliver the "one-click-login"

[slide 2: Process of Telecom Authetication]

[there's a pre-comm phase between app and server to decide if telecom-authn is available or not]

Jiaqiang:pre-authentication phase: to pre-estimate whether this user could use telecom-authn or not, via a pre-authn logic
... authentication phase: to formally launch the authentication and retrieve the token, with interaction with user.
.. login phase: to login with token

[slide 3: Scenario 1 - Auto Login]
... the apps ascuiremobile phone numbers by communication network
... then use the phone numbers to login
... right now, we provide SDK to support this feature
... it is faster, login within 3 seconds
... it is safer, than password and login with short messages(SMS)
... more efficient, in this scenario, you do not do the seperate registration anymore, login is integrated with registration.


@@2: will this provide more registration information?

Jiaqiang: No. only provide mobile number in lightweight user scenario.

Sam: if the user change the operator, the history will get lost.

Jiaqiang: (continue)

... Scenario 2, phone number checking

Jiaqiang: we're workong on number portability

[slide 5: application status]

sam: absent norber portability, this is just more user lock-in. this is user-hostile!
... by may 2019, average active users 210 millions per day

[slide: 1.16B auths/day, 210M users/day, 2600+ apps]

Sam: it is widely used
... [slide: security concerns]
... aspect 1: XSS attack risks
... attackers could put malicious code in website
... the target server may return token to user
... aspect 2: mobile hotspot security risks
... in mobile hotspot cases, the token of hotspot sponsor might be leaked

[slide: solutions]
... ll these risks has been solved by our SDK ways now
... SDK testifies the app id and sim card info, thus the attacker can no longer fake the user to login

[slide: expectations of web standardization]
... we propose to promote a wider acceptance of telecom authentication
... and apply the telecom authentication to the browser/server applications
... we hope to make the telecom authn standardized in W3C
... to help solve the problem i just mentioned

gerhard: are sim-swap attacks - which are often used - have you seen those?

Jiaqiang: have not seen this. can't logout.

Sam: if i lost my phone, i will request a new simcard from vendor

gherardt: we have a N-hour sim-swap lockout - we won't allow access if sim has been swapped in an interval

<Zakim> dsinger, you wanted to ask how the service and operator interact to get the phone number and verify it’s authorized for this service

Sam: what is the information exchanged during the Pre-authentication phase (phase 1-3)

Jiaqiang: not much detail

Sam: how detailed of a spec do you have?

Jiaqiang: very detailed.

gherardt: important problem

@@3: used for login, not payment

gherardt: trend is to use both something you have and something you know. this helps with the former

@@3: this does not replace PW; this is for login. - replacing SMS code for login.

nick: people bristling at using this as primary auth. this flow is something we commonly do.
... CEO of twitter just had a sim-swap attack hit him. I'm curious re: attestation of SIM card - not just phone number.
... could this sign a claim of "here's the last time this SIM was swapped"?

Jiaqiang: repeating: besides phone number, any other identifies?

nick: any more info that can be attested to? more info might be useful.

gerhardt: non-PII.
... e.g. IMSI hash

Sam: hash is still linkable
... linkable is still an issue

nick: I'd claim linkability isn't an issue w/ the spec.
... We will have to use phone numbers to solve some problems.

Jiaqiang: maybe we could build a mechanism ... let user know IMSI number connected to other accounts.

jeffh: GSMA Mobile Connect - are you aware of it?

Jiaqiang: not aware of it. but engaged with GSMA.

jeffh: GSMA Mobile Connect seems similar.
... verification of user is possession of phone, right?

GSMA Mobile Connect: https://www.gsma.com/identity/mobile-connect

Jiaqiang: yes.

jeffh: what if my lock screen is turned off?

Jiaqiang: very dangerous.
... use this for low-value situations.

jeffh: so you do step-up auth.
... if you wanted to attack the pw problem - which isn't doesn't sound like you're doing, since you're still using PWs in other contexts.

<Zakim> dsinger, you wanted to talk about authorization and identification

dsinger: you're replacing a PW - proof of authorization - with identity, which is bad for privacy

nick: important to separate technical means of assocaiting user with number and .... still ahve to solve that problem sometimes.

dsinger: you're encouraging a lot of service to identify users. that is the problem

gerhardt: I see this angle. looking at EU stds... there must have been an initial registration to get phone number.
... this is to confrim ownership of number already linked

sam: not what I heard

dsinger: if I wanted a BB acount - could create an anon acct w/ PW. they don't know it's dsinger, just someone w/ an account. if they move to this, they know the phone number and all accoutns everywhere associated.

gerhardt: I'm thinking from lens of a finacial instituion w/ KYC requiremetns

<Zakim> Jv_, you wanted to talk about payment request api and this

@@4: universal authen. probably don't need to associate access rights w/ ID. but as extension for imission-critical apps, people dont' want to create new acct.

scribe: they're going to provide identity anyway, this is ok. for other scenarios - social networks - you have some other options. they are trying to provide a new option for mission cirital apps.

dsinger: @5

Jiaqiang: please look at animation again.

Lilin:Mobile Connect Platforms and Operations services, mobile connnect SDK, https://www.gsma.com/identity/wp-content/uploads/2019/03/mc_mwc_platforms_booklet2_web_02_19-1.pdf

<Zakim> jv, you wanted to talk about payment request api and this

dsinger:there are probably ways to set it up such that the service and the MNO set up service-specific identifiers, such that the service is NOT given the phone-number, but something that can’t be correlated with a specific person and their uses of other services.

jv: webpayments WG, payment req API; this is useful: get phone number - send to bank - they send a code - web browser can pick it up....

gerhardt: I'd go past this - if you can passively verify - bank has phone # - can we in background attest to it - pass token to bank to validate token - don't need sms
... use this in a assive way w/o user involvement.
... bank can say I expect this from this number, is it from there?

dsinger: @6

jv: big problem in payment request is how to auth user in few steps.

sam: this is intertwining identity ... you might need only to AUTHORIZE a user, not identify them
... why does this take 3 secs?
... that seems slow.

Jiaqiang: haven't heard that Q before.
... my colleague says 1 sec.

Sam: security concern aspect 2, how do you avoid sending to the wrong party

Jiaqiang: we switch to mobile network?
... are we trusting the whole network?

gerhardt: to nick's point, this is a real point that we want to solve... having a way to attest to a phone number.. browser agent has the ability to swap to LTE/3G not just 802.11. has ability to make call to mobile network operatro. many organizatios around this world will want to o this. right aporach: not sure. but worthwhile for w3c to explore solving. this is a tough problem to solve. solving it in a good way.
... is good for the net.

JV: would have to be in collaboration w/ GSMA. in payments, working w/ fida and EMVco. GSMA has a role to pay.

dsinger:I'm coming across as negative, but I'm more negative about PWs.

scribe: not sure w3c should be doing a solution that is specific to (only) mobile.

gerhardt: US has new protocol to prevent spam/robot calls. maybe shaken/stir fits in?

Chunming: if we have many fixes to soln, how to we integrate this into webauthn framework?

gerhardt: web authnn tests for the person - that there is a person present. and that a biometric cred is presented

Sam: disagree with you again. Webauthn is more about device.

Jiaqiang: maybe your device and PW are not safe... cannot say PW must be safer than device - both PW and device are auth

Sam: how does this compare to building a webauthn device into a phone?

gerhardt: we have this more for registration - not the day-to-day authn. want number at start, for registry.

Summary of Action Items

Summary of Resolutions

[End of minutes]

Minutes manually created (not a transcript), formatted by David Booth's scribe.perl version 1.154 (CVS log)
$Date: 2019/09/19 05:59:50 $