vKT8vU91

1Discuss changes to the GD NOC for ENRQ-1519
2
3Hello,
4 
5I am trying to putting a high level design for ENRQ-1519 ( see https://wikis.rim.net/display/besng/Activation+Against+UEM+over+BB+Infrastructure ). In this design, UEM will not publish the access key hash to GD NOC and  containers will activate without calling provEnterpriseNOC during this first phase. I am attaching email thread for further explanation and a proposal on how to overcome this.
6 
7I would  like to discuss the impact of making this change to the GD NOC.
8 
9Please forward to anybody else you feel should attend.
10 
11Re: Continue the high level review for ENRQ-1519
12 
13Thank you.
14 
15admins/user will create an activation password
16a record will be published into the discovery service
17user will enter the activation password
18client will detect that it is an activation password and will follow the new flow :
19Do anonymous activation against NOC ( for purposes of GNP )  
20Retrieve ALL activation information from the discovery service for the user id.
21Attemp to activate for each record until successful.
22The client will now have enough information to proceed with CMP/CTP protocol, etc. 
23
24 Activation Use Cases
25UEM Enrollment Service is acting as as Certificate Authority and will be issuing certificate identities to dynamics applications. It will keep track of all valid certificates that have been issued. UEM allready stores this information in DB for UEM client ( via usr_dvc_cert_catalog table ) and this should be extended to include information about certificates issues to dynamics applications. 
26UEM will call allowRemoteHostEnterpriseService of Enterprise Server GW (MDC) to allow enterprise services for a specific dynamics containers. Since the clients will not be calling provEnterpriseNoc call to the MDC at the beginning of the activation, the MDC will not be able to confirm that a terminalID ( obtained through OTA activation servlet ) belongs to a particular tenant ( done by matching the pin hash ). This means that UEM's call to allowRemoteHostEnterpriseServices will fail as the MDC will not be able to confirm that a terminalID is registered against a particular organization/tenant. To remedy this, the allowRemoteHostEnterpriseService should be changed so that it updates the terminal data and associate it with the correct organization and enterpriseTerminalID provided in the allowRemoteHostEnterpriseService call. If the mapping already exists, the allowRemoteHostEnterpriseService call should behave as it currently does ( fail if the mapping is not correct ). This way it will be backwards compatible with legacy activation.  With this proposal, there is a possibility of a DOS attack whereby a rogue UEM can "hijack" the terminal IDs and associate them with their own organization. This would prevent a legimate container against activating against a legimate UEM. However, there are couple of things that are mitigating the concerns :   
27It is a very complicated DOS attack - the attacker must posses a legimate UEM with a known tenant. 
28We have means of identifying and revoking the rogue UEMS to stop them from blocking legimate activations.  The legimate customers would only need to re-try the activation process.
29
30
31Unlock Use Cases  
32The unlock access keys are generated and associated with a specific container in order to recover Master Container Key. The container follows a very similar activation flow as when it is first activating. In the provisioning response, the container is provided a TUK ( tempunlockkey ) that it can use to unlock the container. The proposal below is minor modification to this flow to use activation password instaead of the access key.  
33A new CMP featureSet "ActPwd" will be introduced to indicate that parties support activation passwords.  When the admin wants to generate an unlock credential, the server will know if a given dynamics container supports "ActPwd" or not. If it does, it will ask the admin if they want to generate/specify an activation password for unlocking purposes. When the activation password is created, it will be marked with the containerId. This will allow the enrollment service to identify which container record to use to generate TUK in the response to provisioning request. UEM will register a record with discovery service when the password is created. 
34The following table captures all the use cases : 
35SDK Version
36Old UEM
37New UEM
38NEW CLIENT	
39UEM will generate access code
40Clients will follow the legacy protocol
41UEM knows the capabilities of the endpoint. It will ask the admin to enter the activation password manually or it will auto generate it.
42A record will be published into the discovery service.
43User will enter the activation password into the locked application
44Client will obtain a new temp terminal ID from MDC( existing behaviour )
45Client will use new activation protocol and include the unlockContainer flag in the ProvDataRequest
46UEM will process the provision request including calling MDC.allowRemoteHostEnterpriseservices() with both new and old terminal Id ( existing behaviour ) and respond to clients
47Client will unlock the container using TUK ( existing behaviour )
48Clients will send deactivate Terminal command to MDC for new temp Terminal ID ( existing behaviour )
49OLD CLIENT	
50UEM will generate generate access code
51Clients will follow the legacy protocol
52UEM knows that the old clients do not support activation passwords so it will generate access key for the administrator without asking
53Clients will proceed with legacy way of unlocking the locked container.
54The public API of UEM will similiarly have to generate the activation password instead of the access code for containers that support the "ActPwd" capability.  The API signature does not have to change, only the return value. 
55
56
57Easy Activation Use Case
58The CMP protocol RequestActivationInfo message will be extended to include the preferActPassword. It will be an optional field sent by the clients to the UEM servers that are capable of "ActPwd" feature. UEM servers that understand the new field will generate the activation password instead of the access code. 
59The activation password will be stored in the DB and tagged with the nonce and application ID. This nonce and application-id will be used later to ensure that it can be used only by correct application.