Subject: [KEYPROV] DSKPP -06, "protocol model"

From: <[email-masked]>
Date: Thu, 13 Nov 2008 21:41:46 +0200

Hi,

I promised to send some text explaining what I meant when I complained
that the document doesn't say much about how the DSKPP protocol
entities interact with the rest of the world.

This is basically a "protocol model" (in RFC 4101 sense) of some kind;
explaining how the "protocol black box" interacts with the rest of 
the world, and a high-level view of the protocol internals (but omitting
the details that could be changed without the the world outside DSKPP
noticing).

This text would basically replace much of Section 1 and perhaps parts
of Section 3. I've also suggested some terminology changes to better
align this with PSKC, and make it easier to understand overall.
However, this text certainly isn't meant to be cut-and-pasted as is
to the DSKPP draft -- it's a sketch, not ready text.

Comments are welcome -- especially about what other message flows
we need (but the 25+ different ways of doing client-side authentication
is clearly not what we want here -- and the scope of DSKPP needs
to match the scope of PSKC.)

Best regards,
Pasi

---------------------------------------------------------------------------

1. Introduction

   With increasing use of symmetric key based authentication systems,
   such as one-time passwords (OTP) and challenge-response mechanisms,
   the problem of how the required symmetric keys are provisioned to
   the authentication tokens and authentication servers.

   Traditionally authentication tokens have been provisioned with keys
   during manufacturing, and they have been imported to the
   authentication server from, e.g., a CD-ROM disc shipped with the
   tokens. Some vendors also have proprietary provisioning protocols,
   which often have not been publicly documented (CT-KIP is one
   exception [RFC4718]).

   This document describes the Dynamic Symmetric Key Provisioning
   Protocol (DSKPP), a client-server protocol for provisioning
   symmetric keys between an authentication token (corresponding to
   DSKPP client) and an authentication server (corresponding to DSKPP
   server).

   In some respects, DSKPP is the symmetric key counterpart of
   certificate management protocols such as CMC [RFC5272], CMP
   [RFC4210], and SCEP [draft-nourse-scep].

1.1 Protocol Entities

   The following terms describe the most important entities
   on the "client side":

     Authentication Token: A device or software component that uses 
     symmetric key(s) to support authentication (for example,
     one-time passwords or challenge-response) using one or more  
     Token Algorithms.

     Token Algorithm: Determines the allowed lengths of the Token Key,
     the cryptographic operations that can be performed (e.g. OTP
     computation or challenge-response) and their inputs, outputs, and
     algorithms; and what Token Attributes can be used. (TODO: This is
     called "Key Type" in PSKC, but I think we need a better term.)
     Some examples of Token Algorithms are HOTP [RFC4226], S/Key
     [RFC1760], and SecurID-AES. In DSKPP, Token Algorithms are
     identified by URIs.
      
     Token Key (also K_TOKEN): The symmetric key used by a Token
     Algorithm.  (DSKPP treats this as a single key, although the
     token algorithm could split it to multiple pieces internally.)

     Token Attributes: Set of information that influence how the Token
     Key will be used by the Authentication Token. For example, the
     length of OTP value (for OTP algorithms that support variable
     length OTPs), date after which the Token Key should deactivate
     itself (for tokens which have clocks), or how the token should
     control access to its functionality (e.g. local PIN code).
     (TODO: DSKPP -06 calls this "Key Package", which is slightly
     confusing name for something that doesn't include a key, at least
     in all protocol variants. PSKC calls it "Key Container".)
 
     Hardware Token: A special-purpose Authentication Token, usually
     a small card or key fob like device intended to be carried by
     the user.

     Software Token: A type of Authentication Token that is implemented
     as software on a general-purpose electronic device such as a 
     desktop computer, laptop, PDA, or mobile phone.

     Device:  The physical device implementing the token. For hardware
     tokens, this is the token itself; for software token, it is
     the host device (laptop, mobile phone, etc.)

     DSKPP Client: The logical entity implementing the client part of
     DSKPP protocol. In case of Hardware Token, the DSKPP Client might
     run on a PC to which the Hardware Token is connected.  In case of
     Software Token, the DSKPP Client could be part of the same
     software package as the token itself. (The interface between the
     token and the DSKPP Client is not specified in this document --but
     see Appendix B for an example.)

   The corresponding entities on the "server" side are as follows:

     Authentication Server: A server that uses symmetric key(s) to 
     support authentication with the Authentication Token (for 
     example, verifying One-Time Passwords).

     DSKPP Server: The logical entity that communicates with the DSKPP
     client. This functionality may be implemented in the same
     software package as the Authentication Server, or it can be a
     separate software package. (The interface between DSKPP Server and
     Authentication Server is beyond the scope of this document.)
  
1.2 Message Flow 1: Initial Provisioning with Authentication Code
   
   In the first message flow, the user has obtained a new hardware or
   software token, and the goal is to provision the same symmetric
   key(s) and related information to the token and the authentication
   server, and associate the token with the correct user name (or
   other account identifier) on the server.

   In the following example, the user is authenticated using a Client
   ID and Authentication Code -- essentially a user name/password
   combination that is used only once, and then discarded. Other
   mechanisms for user authentication are described in ...TODO.

   The Authentication Code is typically generated by the DSKPP Server,
   and delivered to the user via out-of-band trustworthy channel (for
   example, a paper slip delivered by IT department staff). The Client
   ID is used by the DSKPP Server to find the corresponding
   Authentication Code; it can be a short random identifier (unrelated
   to any real user names). The DSKPP Server also needs to know the
   long-term user name (or other account identifier) that this token
   will be associated with.

   The user typically enters the Client ID and Authentication Code
   manually, possibly on a device with only numeric keypad. Thus, they
   are often short numeric values (for example, 8 decimal digits).
   However, the DSKPP Server is free to generate them in any way it
   wishes.
   
   The DSKPP client also needs the URL of the DSKPP server (which is
   not user-specific or secret, and may be pre-configured somehow),
   and a set of trust anchors for verifying the server certificate.

   Auth.         DSKPP                          DSKPP            Auth. 
   Token         Client                         Server          Server         
    |              |                              |               |
    |              |                +---------------------------+ |  
    |              |                | Server receives User      | |
    |              |                | Name, creates and stores  | |
    |              |                | Client ID and Auth. Code, | |
    |              |                | and delivers them to the  | |
    |              |                | user out-of-band.         | |
    |              |                +---------------------------+ |
    |              |                              |               |
    |  +------------------------+                 |               |
    |  | User enters Client ID, |                 |               |
    |  | Auth. Code, and URL    |                 |               |
    |  +------------------------+                 |               |
    |              |                              |               |
    |              |<-- 1. TLS handshake with --->|               |
    |              |        server auth.          |               |
    |              |                              |               |
    |              | 2. KeyProvClientHello ------>|               |
    |              |                              |               |
    |              |<---- [3. KeyProvServerHello] |               |
    |              |                              |               |
    |              | [4. KeyProvClientNonce] ---->|               |
    |              |                              |               |
    |              |<--- 5. KeyProvServerFinished |               |
    |              |                              |               |
    |<-- Token Key |                              | Token Key & ->|
    | & Attributes |                              | Attributes,   | 
    |              |                              | User Name     |          
 
                    Figure X: Basic DSKPP Exchange

   In Step 1, the client establish a TLS connection, and authenticates
   the server (that is, validates the certificate, and compares the host
   name in the URL with the certificate). 

   Next, the DSKPP Client and DSKPP Server exchange DSKPP messages
   (which are sent over HTTPS). In these messages,

   -  The client and server negotiate what token algorithms they
      want to use; what algorithms are supported for protecting DSKPP 
      messages, and other DSKPP protocol details.

   -  The client sends the Client ID to the server, and proves that 
      it knows the corresponding Authentication Code.

   -  The client and server agree on a secret key (token key or
      K_TOKEN); depending on the negotiated protocol variant, this is
      either generated by the server (or already exists on the server)
      and transported to the client (called "two-pass variant" in the
      rest of this document, since it involves two DSKPP messages), or
      it is a fresh key derived during the DSKPP protocol run (called
      "four-pass variant", since it involves four DSKPP message).

   -  The server sends a "key container" to the client. The container
      does not include the key itself, but token attributes that
      influence how the token key will be used by the Authentication
      Token and Authentication Server. The exact contents depend
      on the token algorithm (e.g., for an OTP algorithm that supports 
      variable-length OTP values, the length of the OTP value would
      be one attribute).      

   (TODO: I might be missing import details here, depending on 
   exactly which profile is used.)
   
   After the protocol run has been successfully completed, the
   Authentication Token stores the token key and the attributes.
   Likewise, the Authentication Server stores the token key and the
   attributes, and associates these with the correct user name. The
   user can now use the Authentication Token to authenticate to the
   Authentication Server.

   The exact division of work between the Authentication Token and the
   DSKPP Client -- and Authentication Server and DSKPP Server -- are
   not specified in this document. The figure above shows one possible
   case, but this is intended for illustrative purposes only.

1.3 Message Flow 2: Initial Provisioning with Web Authentication

   In the first message flow (previous section), the Client ID and
   Authentication Code were delivered to the user by some out-of-band
   means (such as paper). 

   Web .         DSKPP                          DSKPP            Web   
   Browser       Client                         Server          Server         
    |              |                              |               |
    |<-------- HTTPS browsing + some kind of user auth. --------->|
    |              |                              |               |
    | some HTTP request ----------------------------------------->|
    |              |                              |               |
    |              |                              |<------------->|
    |              |                              |               |
    |<------------------------- HTTP response with KeyProvTrigger |
    |              |                              |               |
    | Trigger ---->|                              |               |
    |              |                              |               |
    |              |<-- 1. TLS handshake with --->|               |
    |              |        server auth.          |               |
    |              |                              |               |
    |              |     ... continues...         |               |

           Figure Y: DSKPP Exchange with Web Authentication

   In the second message flow, the user first authenticates to a web
   server (for example, IT department's "self-service" intranet page),
   using an ordinary web browser and some existing credentials.

   The user then requests (by clicking a link or submitting a form)
   provisioning of a new key to the Authentication Token. The web
   server will reply with a "KeyProvTrigger" message that contains the
   Client ID, Authentication Code, and URL of the DSKPP Server.  This
   information is also needed by the DSKPP Server; how the web server
   and DSKPP Server interact is beyond the scope of this document.
  
   The "KeyProvTrigger" message is sent in a HTTP response, and it
   is marked with MIME type "application/vnd.ietf.keyprov.dskpp+xml". 
   It is assumed the web browser has been configured to recognize
   this MIME type; the browser will start the DSKPP Client,
   and provides it with the KeyProvTrigger message.

   The DSKPP Client then contacts the DSKPP Server, and uses the
   Client ID and Authentication Code (from the KeyProvTrigger
   messsage) the same way as in the first message flow.
  
1.4 Message Flow 3: Key Replacement/Renewal
  
   (TODO: not yet written)

_______________________________________________
KEYPROV mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/keyprov