Subject: [KEYPROV] KEYPROV terminology

From: <[email-masked]>
Date: Tue, 24 Feb 2009 12:28:49 +0100

Andrea, Philip, others:

I've started to go through DSKPP -07 and PSKC -02, and it seems the
two documents still use different words when referring to basically
same thing, and same words when referring to different things.

If the documents were just using different words to refer to the same
thing, aligning them would be a rather simple (just decide on what we
call this, and do a search-replace). But much more importantly, it
looks like there's no agreement about what entities we're naming in
the first place (and it seems neither DSKPP nor PSKC are even
internally consistent about this, and use a single word to mean
several different entities).

In my 2008-11-13 email, I proposed one set of terms that I hoped would
work for all three documents (has terms for all the major entities in
DSKPP and PSKC), and would be internally self-consistent.  Actually,
comparing this to the latest DSKPP and PSKC drafts, I see that I was
actually missing several key terms needed for PSKC.

I'm not particularly committed to that terminology, and as I noted
above, it's much more important to agree on what we're naming than the
actual name. Some folks already commented that they'd prefer something
else than "authentication token" to make it easier to use DSKPP/PSKC
for other non-authentication things in the future (although the
current WG charter is restricted to authentication tokens); that seems
quite reasonable.

I've now gone through both DSKPP and PSKC again, trying to figure out
what needs to be named.  I've replaced the actual words with
AAA/BBB/etc., so we could separate the discussion "what entities we
need to name" from "what words we should use to name them" (one
possible proposal for the names is included below, though)

   AAA: A hardware or software component that implements one or more
   BBBs.

      Hardware AAA: A special-purpose AAA implemented on dedicated
      hardware.

      Software AAA: A type of AAA that is implemented as software on a
      general-purpose system such as a desktop or server computer,
      laptop, PDA, or mobile phone.

   CCC: The physical device implementing the AAA. For hardware AAAs,
   this is the hardware itself; for software AAA, it is the host
   device (laptop, server, mobile phone, etc.)

   BBB: A component that performs symmetric key operations using a BBB
   Algorithm, BBB Key, and BBB Attributes, and other state.

      Example: A BBB implemented on a small card or key fob like CCC
      ("authentication token"; one kind of hardware AAA) could compute
      one-time passwords based on the key and some internal state
      (such as counter or time). Another BBB, probably implemented in
      software AAA on a server CCC, would verify the one-time
      passwords.  Obviously, both BBBs need to share the same key and
      algorithm for this to work.

      Example: A software one-time password program (one kind of
      software AAA) could contain several BBBs (with different BBB
      Keys) for authenticating with different providers or accounts.

   BBB Algorithm: Determines the allowed lengths of the BBB Key, the
   cryptographic operations that can be performed (e.g. OTP
   computation or challenge-response) and their inputs, outputs, and
   algorithms; and what BBB Attributes can be used.

      Example: some examples of one-time password BBB Algorithms are
      HOTP [RFC4226], S/Key [RFC1760], and SecurID-AES. In DSKPP and
      PSKC, BBB Algorithms are identified by URIs.

   BBB Key: The symmetric key used by a BBB Algorithm.  (DSKPP and
   PSKC treat this as a single key, although the BBB algorithm could
   split it to multiple pieces internally.)

   BBB Attributes: Set of information that influence how the BBB Key
   will be used by the BBB Algorithm, and how the BBB can be used.

      Example: The length of OTP value (for OTP algorithms that
      support variable length OTPs), date after which the BBB should
      deactivate itself (for AAAs that have clocks), or how access to
      BBB functionality should be controlled (e.g. local PIN code).

   GGG: An user, account, role, or other entity that uses the services
   provided by BBB, or is otherwise associated with it.

      Examples: The user who owns the one-time password token.  The
      server to which an encrypted hard disk is attached.  The
      communication link being protected by a link encryptor.

   DDD: A data structure for moving a BBB from one AAA to another.
   Contains data about the BBB (e.g. Key and Attributes), AAA and CCC
   (e.g. source or intended destination AAA/CCC), GGG, and FFF.

   EEE: A data structure or file containing one or more DDDs.

      Example: A box of hardware authentication tokens could be
      shipped with a CD-ROM containing an EEE, containing the keys and
      attributes for the tokens.

      Example: A one-time password backend server (one kind of
      software AAA) could allow exporting its state to an EEE for bulk
      import on another server.

   DSKPP Client: The logical entity implementing the client part of
   DSKPP protocol; communicates with an AAA to provision BBBs to the
   AAA. In case of Hardware AAAs, the DSKPP Client might run on a PC
   to which the Hardware AAA is connected.  In case of Software AAAs,
   the DSKPP Client could be part of the same software package as the
   AAA itself. (The interface between the AAA and the DSKPP Client is
   not specified in this document.)

   DSKPP Server: The logical entity that communicates with the DSKPP
   client; usually communicates with a server-side AAA so that a
   corresponding BBB (with the same BBB Key) exists also on the server
   side. The interface between the DSKPP Server and the server-side
   AAA is beyond the scope of this document.

   FFF: An organization or party that manages some BBBs (and possibly
   AAAs) or has some kind of authority over them. Often the
   organization responsbile for DSKPP Server and the server-side AAA.

In UML, the conceptual model could look something like this:

   +----------------------+    runs on    +--------+
   |        AAA           |-------------->|  CCC   |<----+
   +----------------------+               +--------+     |
              | 1         ^                              |
              | contains   \-----------------------------+
              V *                                        |
   +----------------------+                              |
   |        BBB           |  is managed by   +-------+   |
   |----------------------+----------------->|  FFF  |<--|
   | Algorithm            |                  +-------+   +
   | Key                  |  is used by/for  +-------+   |
   | Attributes           |----------------> |  GGG  |   |
   +----------------------+            0..1  +-------+   |
             ^                                   ^       |
             |                                   |       |
            / \----------------------------------+-------+
            \ /
             | represents state about BBB contained on AAA/CCC
             | used by/for GGG, and managed by FFF
             |
   +----------------------------+
   | DDD                        |
   +----------------------------+
   | BBB Algorithm              |
   | BBB Key                    |
   | BB Attributes              |
   | AAA Identifiers/Attributes |
   | CCC Identifiers/Attributes |
   | FFF Identifiers/Attributes |
   | GGG Identifiers/Attributes |
   +----------------------------+
             ^ *
             | contains
             | 1
   +----------------+
   |        EEE     |
   +----------------+

Comparing these vs. dskpp-07, I think the mapping would roughly be

   crypto[graphic] module ~ means either AAA or BBB, depending on context
   device ~ CCC
   key provisioning server ~ server-side AAA
   key type ~ BBB algorithm
   key usage attributes ~ BBB attributes
   key package ~ means either BBB attributes or DDD, depending on context
   K_TOKEN ~ BBB key
   issuer ~ FFF
   user ~ GGG

And vs. pskc-02

   key container ~ EEE
   token ~ means either AAA or BBB, depending on context
   meta data ~ BBB attributes
   device ~ either AAA or CCC
   key ~ means either BBB, BBB Key or DDD, depending on context
   key data ~ means BBB Attributes or BBB Key, depending on context
   key algorithm ~ BBB algorithm
   issuer ~ FFF
   user ~ GGG

One proposal for concrete names would be:

   AAA = cryptographic module
   BBB = [cryptographic] object? or [cryptographic] token?
   CCC = device
   DDD = object package? token package?
   EEE = object|token package container?
   FFF = issuer
   GGG = user

Comments? What in this would/would not work nicely for DSKPP or PSKC?
Suggestions for less cumbersome names?

BTW, if folks think it would help coordinating the drafts, I could
submit the terminology proposal as short Internet Draft (not meant to
be published as RFC), and keep it up-to-date.

(In hindsight, having such a working draft two years ago might have
made the work smoother. But that's hindsight...)

Best regards,
Pasi