Key Provisioning Use Cases and Requirements

1. Key Provisioning Use Cases and Requirements 67th 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