Subject: [KEYPROV] Comments regarding Requirements

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 04 Jul 2007 22:32:41 +0200

Hi all,

I have a few comments to the requirements per the updated draft version:
http://www.tschofenig.priv.at/svn/keyprov/work-in-progress/draft-doherty-keyprov-dskpp-01.txt

Appendix C.  Requirements

   This section specifies mandatory and desirable protocol requirements.

   Req-1:

      The protocol MUST support multiple types of keys for symmetric
      key-based authentication methods.

[hannes] When we have the definition for "key type" then this 
requirement will
be much easier to understand. I suggest to simplify it with:

"
      The protocol MUST support multiple key types whereby a client has to
      express the key type it wants to get provisioned. It MUST
      be possible to define new key types without re-issuing a new 
specification.
"

   Req-2:

      The protocol MUST support re-generated symmetric keys (by separate
      key issuance service) or locally generated keys in real-time (by
      provisioning server).

[hannes] It is difficult to know what the protocol implication is.

   Req-3:

      The protocol MUST support mutually generated symmetric keys by
      both client and server (i.e., joint key control).

[hannes] I added the term "joint key control" since I assume that's what 
is meant here.
Please not that not all DSKPP versions support this property.

   Req-4:

      The protocol MUST allow devices to host multiple symmetric keys;
      each key MAY be acquired in a separate provisioning session.

[hannes] This requirement is fine except for the fact that we use a 
different terminology,
namely cryptographic token, in other places to refer to the keying 
material, algorithms, and context information that is provisioned. 
Hence, we might want to use the same terminology here as well.

This requirement seems to imply that there is a bulk provisioning 
capability as well where you can
obtain more than one cryptographic token with a single protocol exchange.

   Req-5:

      The protocol MUST support renewal of a symmetric key with the same
      key ID.

[hannes] Cannot you just re-run the protocol to produce a key (with 
algorithms, etc.)?
What is the actual implication for the protocol based on this requirement?

   Req-6:

      The protocol MUST allow clients to specify their cryptographic and
      security capabilities to the server and the server to indicate the
      cryptography and algorithm types that it will be using.

[hannes] I think you want to say more than just "capabilities".
The client might want to present the cryptographic algorithms it wans to 
use
with the cryptographic token, it wants to use in the protocol run 
itself, identity information,
etc.

   Req-7:

      The protocol MUST support mutual authentication and
      confidentiality of sensitive provisioning data.

Fine.

   Req-8:

      The protocol MAY use a public-key infrastructure and the use of
      client certificates for device authentication or symmetric key
      data protection.  The protocol MUST allow for other mechanisms,
      such as symmetric key-based techniques, to be used.

Fine.

   Req-9:

      The protocol SHOULD NOT only rely on transport layer security.  It
      SHOULD be compatible with transport layer security when available.

Fine.

   Req-10:

      The protocol MUST carry key expiration date set by the key issuer.

Fine

   Req-11:

      The protocol SHOULD allow the server to use pre-loaded symmetric
      transport keys on a device-by-device basis (i.e., smart card
      update keys, such as used by Global Platform for establishing a
      secure channel).

I am not sure I understood this requirement.

   Req-12:

      The protocol MUST protect against replay attacks.

Fine

   Req-13:

      The protocol MUST protect against MITM attacks.

Fine

   Req-14:

      The protocol MAY support a device request to acquire multiple
      symmetric keys in the same session.

[hannes] delete the term 'device' and replace "in the same session" with 
"with a single request".

   Req-15:

      The protocol MAY allow the provisioning server to verify that the
      key has been correctly provisioned to the client (i.e., key
      confirmation).

[hannes] Since the DSKPP is a two party protocol we should just speak 
about a (DSKPP) client and a (DSKPP) server.
Hence, we could write:

"The protocol MAY allow the DSKPP server to verify that the
      key has been correctly provisioned to the DSKPP client (i.e., key
      confirmation).
"

   Req-16:

      The protocol MAY support a client to notify the server upon
      symmetric key deletion.

[hannes] Hmm. What motivates this requirement?

Ciao
Hannes

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