1. Key Provisioning Use Cases and Requirements 67 th IETF KeyProv BOF – San Diego Mingliang Pei 11/09/2006

2. Use Case 1  A mobile device user obtains an OTP shared secret over the air  A user wants to acquire an OTP secret to use with a software token in its mobile device such as a cell phone  The user registers in the token issuer site to receive a token activation (pickup) code. The secret download URL may be sent to the user device through a message.  The user launches software in the device, or click the pickup URL in a message to download an OTP secret over the air  The client authenticates to the provisioning server with the activation code  The provisioning server generates an OTP secret and assigns a secret ID for the token  The client receives the encrypted OTP secret and associated other token data. The secret is encrypted with a pre-shared secret between the client and the server.

3. Use Case 2  A USB device user obtains an OTP shared secret over internet  A user wants to acquire an OTP secret to use with a software token in its USB flash drive connected to a PC  The user launches software in the device to access provisioning server  The client authenticates to the provisioning server with a device certificate  The provisioning server generates an OTP secret and assigns a secret ID for the token  The client receives the encrypted OTP secret and associated other token data. The secret is encrypted with the public key of the device certificate.

4. Use Case 3  A desktop user obtains an OTP shared secret  A user wants to acquire an OTP secret to use with a software token in its desktop, for example, a browser toolbar application  The user launches software to access provisioning server  The client authenticates to the provisioning server with either an external activation code or domain login  The provisioning server generates an OTP secret and assigns a secret ID for the token  The client receives the OTP secret and associated token data. The secret may be encrypted with a pre-shared secret. It may not be encrypted if the channel between the client and server is secure.

5. Use Case 4  A client acquires a credential over a channel that doesn’t ensure confidentiality and authentication  A user wants to acquire an OTP secret to use with a software token in a mobile device such as a cell phone model that doesn’t support SSL  The user registers in the token issuer site to receive a token activation (pickup) code  The user launches software in the device to access provisioning server to download an OTP secret over the air  The client and server negotiate to establish proper mutual authentication  The provisioning server generates an OTP secret and assigns a secret ID for the token  The client receives the encrypted OTP secret and associated other token data. The secret is encrypted with a pre-shared secret between the client and the server.

6. Other Use Cases  A user acquires multiple symmetric keys of different types  A user wants to provision an OTP software token and a challenge/response token in its mobile device, e.g., a cell phone to access different applications  The device client acquires a symmetric key for each type one by one. Each symmetric key is assigned its ID.  A symmetric key issuer uses a third party provisioning service provider  An issuer outsources its OTP software token secret provisioning to a service provider  A user goes to issuer site to purchase a token and receives an activation code  The software in the user’s device accesses the provisioning service to acquire an OTP secret. The user authenticates to the service with the activation code.  A request may indicate its secret ID prefix assigned to the device manufacturer.

7. Use Cases  A Smart Card client application uses a pre-shared transport key to communicate with provisioning provider  A shared secret encryption key per device is configured in the server side  The symmetric key data in a response is encrypted with the pre-shared encryption key  A key provisioning service imposes a validity period policy for provisioning sessions  After a user starts a provisioning session, a secret must be downloaded within certain period.  When an activation code is acquired, the download period to consume the activation code can be imposed by a server.

8. Use Cases  A user renews its credential with the same credential ID  A user has had an OTP software token in its device  The user wants to upgrade its device or the secret has expired  The user wants to keep the same secret ID so that it doesn’t need to register new ID again to each application that accepts the token  The user requests to acquire a new OTP secret with the same ID  An administrator initiates a credential replacement before it can be used  An administrator wants to replace a pre-loaded symmetric key on a physical token prior to token use. This is a case when reliance on a pre-disclosed secret is unacceptable.  One circumstance is when tokens are issued for classified government use or high security applications.

9. Use Cases  A user acquires a credential through SMS  A user wants to acquire an OTP secret for a software token in an mobile device that support SMS but not enabled data service.  The user goes to a desktop machine to make a provisioning request to provisioning server over HTTPS with proper authentication credential  The request asks the response to be sent through SMS to the user’s mobile device  The user goes to its mobile device to read SMS  A software in the device parses SMS content and decrypt it with pre-shared secret. The OTP secret is then securely saved for software token use.

10. MUST Requirements  Support different symmetric key credential types  OTP, challenge/response, vendor specific  Support multiple credential container formats  Support Portable Symmetric Key Container (PSKC) format  Allow for multiple credential provisioning to the same device  Credential can be acquired in its own session  Allow for provisioning of pre-generated credentials and real-time generated credentials.  Support mutually generated secrets by both client and server  Some considered this a good to have feature. To discuss.  Support credential renewal using the same credential ID  Provide mutual authentication and confidentiality of sensitive provisioning data  Does not rely on transport level security  Should be SSL-compatible when available

11. MUST Requirements  Support OTA delivery to mobile devices  Support Internet delivery to PC/USB  Allow the client to specify its cryptographic and UI preferences (Logo support) in a request  Support password-based encryption  Allow the server to use pre-shared transport key encryption on a device by device basis  Support device authentication and key encryption with a certificate  Not require a public-key infrastructure and client certificates  Support user authentication prior to provisioning  Extensible to support future new algorithms and associated configuration data

12. MAY Requirements  Support a device to acquire multiple credentials in the same session  Allow the server to verify that the key has been correctly provisioned to the client  Allow a client to notify credential deletion to server  Allow for trigger message to couple previous browsing session to start of protocol  HTTP binding with new specific header type

13. NON Requirements  Support credential upload from client to server  Support credential lifecycle management, for example, disabling a token when an owner reports that it is lost; it is an authentication system function.  Support asymmetric key pair provisioning