1 / 13

Key Provisioning Use Cases and Requirements

Key Provisioning Use Cases and Requirements. 67 th IETF KeyProv BOF – San Diego Mingliang Pei 11/09/2006. 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

kueng
Download Presentation

Key Provisioning Use Cases and Requirements

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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

More Related