914685 - [WAP Push] Support WAP Provisioning Bootstrap Authentication for NETWPIN.

Status: RESOLVED FIXED

(Core :: DOM: Device Interfaces, defect)

Description

[Chuck Lee [:chucklee, Triggered by NI, Review, and Feedback requests]]

WAP Provisioning Bootstrap spec[1] described a security mechanism for validating incoming provisioning.
To support such mechanism, we need to include MAC value and WBXML of Provisioning data into system message, so user app can perform the validation.

[1] http://www.wapforum.org/tech/documents/WAP-184-ProvBootstrap-20000223-p.pdf

Comment 1

[José Antonio Olivera Ortega [:jaoo]]

Exposing the IMSI code to content could bring security risks so the authentication process must be perform in gecko. Let's wait the feedback from security team anyway. Thoughts?

Comment 2

[Chuck Lee [:chucklee, Triggered by NI, Review, and Feedback requests]]

(In reply to José Antonio Olivera Ortega [:jaoo] from comment #1)
> Exposing the IMSI code to content could bring security risks so the
> authentication process must be perform in gecko. Let's wait the feedback
> from security team anyway. Thoughts?

It seems that when SEC === NETWPIN, it requires IMSI for HMAC authentication.
I'll handle that part in gecko, and leave USERPIN authentication to gaia.

Comment 3

[José Antonio Olivera Ortega [:jaoo]]

(In reply to Chuck Lee [:chucklee] from comment #2)

> It seems that when SEC === NETWPIN, it requires IMSI for HMAC authentication.
> I'll handle that part in gecko, and leave USERPIN authentication to gaia.

Great, thanks. Also when using SEC === USERNETWPIN, Am I right?

Comment 4

[Chuck Lee [:chucklee, Triggered by NI, Review, and Feedback requests]]

(In reply to José Antonio Olivera Ortega [:jaoo] from comment #3)
> (In reply to Chuck Lee [:chucklee] from comment #2)
> 
> > It seems that when SEC === NETWPIN, it requires IMSI for HMAC authentication.
> > I'll handle that part in gecko, and leave USERPIN authentication to gaia.
> 
> Great, thanks. Also when using SEC === USERNETWPIN, Am I right?

Gecko can't generate a dialog prompt for PIN from user now, that's a problem blocks gecko from handling user pin.

I have considered intercept user pin in gecko, if the user pin is sent to user through SMS(CHT uses class-0 SMS), but it is carrier-specific so might not applied to every carrier.
Another issue is we can't make sure user already know the user pin when we ask for it in gecko.

May you share TEF's method?

Another way is to add a DOM API for WAP Push to get user PIN, but it seems not much preferred in previous discussion.
There might also be synchronizing issue like how long gecko should wait for a valid user PIN before timeout a incoming Provisioning message.

Comment 5

[José Antonio Olivera Ortega [:jaoo]]

(In reply to Chuck Lee [:chucklee] from comment #4)

> I have considered intercept user pin in gecko, if the user pin is sent to
> user through SMS(CHT uses class-0 SMS), but it is carrier-specific so might
> not applied to every carrier.

It might not work 'cause the carrier might have a different mechanism for delivering that authentication information.

> Another issue is we can't make sure user already know the user pin when we
> ask for it in gecko.

I was told by a guy from TEF's provisioning server team the user usually is provided with the PIN before receiving the provisioning message. Typically the PIN is received with a SMS message. 

> May you share TEF's method?

TEF's provisioning server uses NETWPIN as authentication mechanism. That way the authentication of the provisioning message is handled transparently.

> Another way is to add a DOM API for WAP Push to get user PIN, but it seems
> not much preferred in previous discussion.
> There might also be synchronizing issue like how long gecko should wait for
> a valid user PIN before timeout a incoming Provisioning message.

A DOM API would work but in order to avoid the synchronizing issue the user should provide as parameter the message he/she wants to authenticate when calling the function. Let me explain myself. The user would continue receiving the WAP PUSH through the system message. Once he/she realizes the authentication mechanism is USERNETWPIN the app prompts the user for input (the
user PIN) and calls the DOM API function that authenticates the message. This call should provide the SEC and the raw WEBXML and the user PIN values as parameters.

This is what I have in mind right now but I'm open to discuss it. Other approaches are also welcome.

Comment 6

[Chuck Lee [:chucklee, Triggered by NI, Review, and Feedback requests]]

(In reply to José Antonio Olivera Ortega [:jaoo] from comment #5)
> (In reply to Chuck Lee [:chucklee] from comment #4)
> A DOM API would work but in order to avoid the synchronizing issue the user
> should provide as parameter the message he/she wants to authenticate when
> calling the function. Let me explain myself. The user would continue
> receiving the WAP PUSH through the system message. Once he/she realizes the
> authentication mechanism is USERNETWPIN the app prompts the user for input
> (the
> user PIN) and calls the DOM API function that authenticates the message.
> This call should provide the SEC and the raw WEBXML and the user PIN values
> as parameters.
> 
> This is what I have in mind right now but I'm open to discuss it. Other
> approaches are also welcome.

What I thought of is user use such API to assign a one-time-usage PIN, and triggers a authentication of one provisioning message.
If the authentication success, the a system message is sent.

Your method is much simpler and straightforward, I'll check if such authentication is required in other message.
Maybe we can put it in existing DOM like mobilemessage or iccmanager.

Comment 7

[Chuck Lee [:chucklee, Triggered by NI, Review, and Feedback requests]]

Attachment: WIP - Support GSM network pin authentication.

1. Get IMSI and apply HMAC-SHA check on WAP Puch CP message in WBXML form.
2. Add authentication information into wap-push system message.

Comment 8

[Chuck Lee [:chucklee, Triggered by NI, Review, and Feedback requests]]

Now NETWPIN can be handled by gecko, and USERPIN and USERPINMAC can be handled by Gaia.
The problem remains is how to deal with USERNETWPIN.

Options are
1. Add an API for that.
2. Don't support it.
   OEMs/carriers can implement their specific handler according to their USERPIN delivery mechanism.
3. Do a reversible encryption on IMSI and send with system message, Gaia decrypt and retrieve IMSI.
   OEMs/carriers can define their own encrypt/decrypt method.

Comment 9

[José Antonio Olivera Ortega [:jaoo]]

(In reply to Chuck Lee [:chucklee] from comment #8)
> Now NETWPIN can be handled by gecko, and USERPIN and USERPINMAC can be
> handled by Gaia.
> The problem remains is how to deal with USERNETWPIN.
> 
> Options are
> 1. Add an API for that.

I do much prefer this options over the other ones. It would make things much simpler and straightforward.

> 2. Don't support it.
>    OEMs/carriers can implement their specific handler according to their
> USERPIN delivery mechanism.

This option will involve gecko changes (tipically provided by the OEM) and will make gecko carrier-dependent. IMHO this would be really bad.

> 3. Do a reversible encryption on IMSI and send with system message, Gaia
> decrypt and retrieve IMSI.
>    OEMs/carriers can define their own encrypt/decrypt method.

We would need the input from security team. Antonio, would you provide some feedback about the third option please? Thanks.

Comment 10

[José Antonio Olivera Ortega [:jaoo]]

Comment on attachment 811809 [details] [diff] [review]
WIP - Support GSM network pin authentication.

Review of attachment 811809 [details] [diff] [review]:
-----------------------------------------------------------------

::: dom/wappush/src/gonk/WapPushManager.js
@@ +104,5 @@
> +      // Apply HMAC authentication on CP message first
> +      authInfo = CP.Authenticator.check(data.array.subarray(data.offset),
> +                                        options.headers["content-type"]);
> +      if (authInfo && authInfo.checked && !authInfo.pass) {
> +        throw new Error("Invalid CP message.");

IMHO we should send the system message even in case of authentication failures. If so we can show an alert to the use.

Comment 11

[Chuck Lee [:chucklee, Triggered by NI, Review, and Feedback requests]]

Comment on attachment 811809 [details] [diff] [review]
WIP - Support GSM network pin authentication.

Review of attachment 811809 [details] [diff] [review]:
-----------------------------------------------------------------

::: dom/wappush/src/gonk/WapPushManager.js
@@ +104,5 @@
> +      // Apply HMAC authentication on CP message first
> +      authInfo = CP.Authenticator.check(data.array.subarray(data.offset),
> +                                        options.headers["content-type"]);
> +      if (authInfo && authInfo.checked && !authInfo.pass) {
> +        throw new Error("Invalid CP message.");

How about same system message with |authInfo.checked === true && authInfo.pass === false|?

Comment 12

[José Antonio Olivera Ortega [:jaoo]]

(In reply to Chuck Lee [:chucklee] from comment #11)
> Comment on attachment 811809 [details] [diff] [review]

> How about same system message with |authInfo.checked === true &&
> authInfo.pass === false|?

That way we could show an alert letting know the user something like "The configuration message you received could not be authenticated against your SIM card, so cannot be used to configure your device.". Typically CP messages are sent when the user requests some help to the carrier customer service. Let's imagine the user waiting for a message that could not be authenticated. If we don't send the system message the user won't be never alerted.

Comment 13

[Andrew Overholt [:overholt]]

Joe, is this a 1.2 feature?

Comment 14

[Andrew Overholt [:overholt]]

I spoke with Beatriz on IRC and found out this is indeed a committed 1.2 feature.

Comment 15

[Kai-Chih Hu [:khu]]

Add [FT:RIL] in the whiteboard. Ken, could you help to talk with Chuck and fill in the target milestone? Then, we will have a better view on this bug. Thank you.

Comment 16

[Ken Chang[:kenkai]]

Because of security issue, IMSI can not be delivered to Gaia. It is the blocked problem for USERNETPIN.
Before having a consensus, we wound like to only support NETPIN which is partner's requirement in this bugs.
A follow-up issue will be created for other pins.
If it doesn't work for you, please let us know.

Comment 17

[José Antonio Olivera Ortega [:jaoo]]

(In reply to Ken Chang from comment #16)
> Because of security issue, IMSI can not be delivered to Gaia. It is the
> blocked problem for USERNETPIN.
> Before having a consensus, we wound like to only support NETPIN which is
> partner's requirement in this bugs.
> A follow-up issue will be created for other pins.
> If it doesn't work for you, please let us know.

Since the IMSI code is also needed for USERNETWPIN security mechanism this mechanism must be handle by gecko as well. Please, open another bug for it. The development for USERNETWPIN mechanism is more complicated than NETWPIN mechanism (see the discussion in the comments above) and it could take more time than expected. We agree to include the four mechanisms for v1.2 release, don't we? I'm afraid about finishing it on time.

USERPIN and USERPINMAC mechanisms will be handled in Gaia side. We only need gecko to add to the WAP PUSH message the auth info included in the headers and the WBXML message (raw data). I'm aware the patch in this bug adds this info to the message sent by gecko.

Comment 18

[Chuck Lee [:chucklee, Triggered by NI, Review, and Feedback requests]]

Attachment: Support GSM network pin authentication.

1. Send system message on NETWPIN auth fail, per comment 11.
2. Only handle NETWPIN in this bug patch, per comment 17.

Comment 19

[Ken Chang[:kenkai]]

(In reply to José Antonio Olivera Ortega [:jaoo] from comment #17)
> The development for USERNETWPIN mechanism is more complicated than NETWPIN
> mechanism (see the discussion in the comments above) and it could take more
> time than expected. We agree to include the four mechanisms for v1.2
> release, don't we? I'm afraid about finishing it on time.
Bruce, does anyone request the USERNETWPIN? If not, could we remove it from 1.2?

> USERPIN and USERPINMAC mechanisms will be handled in Gaia side. We only need
> gecko to add to the WAP PUSH message the auth info included in the headers
> and the WBXML message (raw data). I'm aware the patch in this bug adds this
> info to the message sent by gecko.
José, will you create the gaia bugs for USERPIN and USERPINMAC?
Thanks.

Comment 20

[José Antonio Olivera Ortega [:jaoo]]

(In reply to Ken Chang from comment #19)

> > USERPIN and USERPINMAC mechanisms will be handled in Gaia side. We only need
> > gecko to add to the WAP PUSH message the auth info included in the headers
> > and the WBXML message (raw data). I'm aware the patch in this bug adds this
> > info to the message sent by gecko.
> José, will you create the gaia bugs for USERPIN and USERPINMAC?
> Thanks.

The support for these mechanism is included in the development for bug 917312. Thanks.

Comment 21

[Chuck Lee [:chucklee, Triggered by NI, Review, and Feedback requests]]

Comment on attachment 815765 [details] [diff] [review]
Support GSM network pin authentication.

The patch is refactoried with help of vicamo, I will upload it once I have it tested.

Comment 22

[José Antonio Olivera Ortega [:jaoo]]

Comment on attachment 815765 [details] [diff] [review]
Support GSM network pin authentication.

Review of attachment 815765 [details] [diff] [review]:
-----------------------------------------------------------------

::: dom/wappush/src/gonk/CpPduHelper.jsm
@@ +173,5 @@
> +    let headerSec = AUTH_SEC_TYPE[headers.params.sec];
> +    let headerMac = headers.params.mac.toUpperCase();
> +    if (!headerSec || !headerMac) {
> +      return null;
> +    }

Chuck, a last minute comment. There is a certification requirement about that. See bellow please.

DESCRIPTION:
1. Create a client provisioning document. 
2. Send  it to the device using SMS and without any security mechanism.
EXPECTED RESULT:
The device must ignore the client provisioning document sent.

So gecko wouldn't need to send the message to gaia at all.

Are you ok with that? Thanks!

Comment 23

[José Antonio Olivera Ortega [:jaoo]]

Comment on attachment 815765 [details] [diff] [review]
Support GSM network pin authentication.

Review of attachment 815765 [details] [diff] [review]:
-----------------------------------------------------------------

::: dom/wappush/src/gonk/CpPduHelper.jsm
@@ +180,5 @@
> +      pass: false,
> +      checked: false,
> +      sec: headerSec,
> +      mac: headerMac,
> +      data: wbxml

I'm not able to receive correctly the data property in Gaia side. For example, the length of that array is always undefined. Something's fishy here. Maybe the object sent through the system message is too complex and the system message manager is not able to handle properly (just guessing). Have you tried to read this data in Gaia side? Thanks.

Comment 24

[Chuck Lee [:chucklee, Triggered by NI, Review, and Feedback requests]]

(In reply to José Antonio Olivera Ortega [:jaoo] from comment #22)
> Comment on attachment 815765 [details] [diff] [review]
> Support GSM network pin authentication.
> 
> Review of attachment 815765 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> ::: dom/wappush/src/gonk/CpPduHelper.jsm
> @@ +173,5 @@
> > +    let headerSec = AUTH_SEC_TYPE[headers.params.sec];
> > +    let headerMac = headers.params.mac.toUpperCase();
> > +    if (!headerSec || !headerMac) {
> > +      return null;
> > +    }
> 
> Chuck, a last minute comment. There is a certification requirement about
> that. See bellow please.
> 
> DESCRIPTION:
> 1. Create a client provisioning document. 
> 2. Send  it to the device using SMS and without any security mechanism.
> EXPECTED RESULT:
> The device must ignore the client provisioning document sent.
> 
> So gecko wouldn't need to send the message to gaia at all.
> 
> Are you ok with that? Thanks!

The security information is optional for CP[1], so I prefer gecko still send message to Gaia, and let Gaia decide ignore it or not.
For the certification requirement, lack of security information will make the |authInfo| in system message become null.

[1] http://technical.openmobilealliance.org/tech/affiliates/wap/wap-183-provcont-20010724-a.pdf, Clause 5.3. "The connectivity media type **may** contain security information"

Comment 25

[Chuck Lee [:chucklee, Triggered by NI, Review, and Feedback requests]]

(In reply to José Antonio Olivera Ortega [:jaoo] from comment #23)
> Comment on attachment 815765 [details] [diff] [review]
> Support GSM network pin authentication.
> 
> Review of attachment 815765 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> ::: dom/wappush/src/gonk/CpPduHelper.jsm
> @@ +180,5 @@
> > +      pass: false,
> > +      checked: false,
> > +      sec: headerSec,
> > +      mac: headerMac,
> > +      data: wbxml
> 
> I'm not able to receive correctly the data property in Gaia side. For
> example, the length of that array is always undefined. Something's fishy
> here. Maybe the object sent through the system message is too complex and
> the system message manager is not able to handle properly (just guessing).
> Have you tried to read this data in Gaia side? Thanks.

It seems typed array is occupted(or not supported?) in Gaia so data preserves but length attribute is gone.
I will add |dataLength| for that.

Comment 26

[Chuck Lee [:chucklee, Triggered by NI, Review, and Feedback requests]]

Attachment: 0001. Support GSM network pin authentication.

1. Refactoried with help of Vicamo.
2. Add |authInfo.dataLength| per comment 25.

Comment 27

[Chuck Lee [:chucklee, Triggered by NI, Review, and Feedback requests]]

Attachment: 0002. HMAC authentication test case.

Test case for HMAC authentication.

Comment 28

[Chuck Lee [:chucklee, Triggered by NI, Review, and Feedback requests]]

Try for current patch: https://tbpl.mozilla.org/?tree=Try&rev=971bf4f87c3b

Comment 29

[Antonio Manuel Amaya Calvo (:amac)]

(In reply to José Antonio Olivera Ortega [:jaoo] from comment #9)
> > 3. Do a reversible encryption on IMSI and send with system message, Gaia
> > decrypt and retrieve IMSI.
> >    OEMs/carriers can define their own encrypt/decrypt method.
> 
> We would need the input from security team. Antonio, would you provide some
> feedback about the third option please? Thanks.

Sorry, this had fallen from my radar completely. I don't think we would wind anything with this compared to just sending the IMSI to Gaia. It doesn't matter if we send it from Gecko to Gaia in clear form or in encrypted form if Gaia has to know how to decrypt it (and needs to use it on a clear form).

Comment 30

[Vicamo Yang [:vicamo][:vyang]]

https://hg.mozilla.org/integration/b2g-inbound/rev/97fc306366aa
https://hg.mozilla.org/integration/b2g-inbound/rev/4c9135876038

Comment 31

[Kai-Chih Hu [:khu]]

We got r+. Looks like I can assign the target milestone to 10/25. If it's not the case, please remove the target milestone. :)

Comment 32

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/97fc306366aa
https://hg.mozilla.org/mozilla-central/rev/4c9135876038

Comment 33

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-aurora/rev/ccbb7ab73787
https://hg.mozilla.org/releases/mozilla-aurora/rev/7bbdb999c0be

Comment 34

[Bruce Huang [:bhuang] (inactive)]

(In reply to Ken Chang from comment #19)
> (In reply to José Antonio Olivera Ortega [:jaoo] from comment #17)
> > The development for USERNETWPIN mechanism is more complicated than NETWPIN
> > mechanism (see the discussion in the comments above) and it could take more
> > time than expected. We agree to include the four mechanisms for v1.2
> > release, don't we? I'm afraid about finishing it on time.
> Bruce, does anyone request the USERNETWPIN? If not, could we remove it from
> 1.2?
> 

Considering it's a pretty big feature to add, we can hold off on it for 1.2.  However, there are partners that do use this mechanism so we need to review the technical pieces required to get it working.