Subject: [KEYPROV] [DSKPP] comments on the current DSKPP spec from Philip Hoyer

From: "Philip Hoyer" <[email-masked]>
Date: Mon, 24 Sep 2007 12:24:17 +0200

COMMENTS:

4.2.2

            Key wrapping normally is intended as a generic mechanism
that can be used with symmetric and asymmetric keys. Is there a reason
for the distinction between Key Transport and Key Wrap? These methods
need alignment with the protection mechanism s in PSKC so for example a
pre-shared key label or index should be supported.

Two Pass DSKPP

What about a use case where DSKPP server does not generate the keys
itself but wants to provision Ks (obtained form a credential provider)
directly to the device without derivation. Do we support this? The other
use case of this is that a key K is generated inside an HSM and then
exported WRAPPED, this key would then need to be provisioned via DSKPP
to the device without other derivations.

4.3.1.1 Unless the use of the private key of the certificate is
protected with a credential like a PIN this would not authenticate the
user but only be a proof of possession of the device

4.3.1.3 What hash algorithms are supported, should we define that
certain algorithms MUST be supported? Can the client transmit which
algorithm was used in case more than one is supported?

General comments about authentication section 4.3

There is a lot of work and a proliferation of protocols that has been
done for mutual authentication in the smart card world for the setup of
secure channel mechanisms. Global platform SCP01 and SCP02 are some
examples. I suggest we take this into consideration.

Matter of fact if one would think of piggy backing those ideas the
authentication would be multiple pass and result in a generation of
secure communication session keys that can be used by DSKPP to protect
the payload or used to generate the keys.

It is not very clearly defined what authentication is mandated (eg proof
of possession of device) whereas the initial statement talks about user
authentication.

4.5.2 

The k is mandated as 16 octets, in section 4.6 the example is: 

K_TOKEN = DSKPP-PRF (R_C, "Key generation" || k || R_S, dsLen)

So R_C representing k MUST be 16 octets 

But section 4.2.1 we state:

"Based on information contained in the <ServerHello> message, the
cryptographic module generates a random nonce, R_C. The         length
of the nonce R_C may depend on the selected key type."

4.8.1.1

Should we use whitespace characters in the string inputted into MAC, I
suggest '_' is better than whitespace ' ' since whitespace can be
represented by ASCII 32 and extended ASCII 255. So I suggest using
'MAC_1_computation' Same for all strings used as input into MACs.

4.8.2.1

"Further, the server is REQUIRED to include an identifier, ID_S, for
itself (via the key container) in the <ServerFinished> message."

The format for ID_S is not defined. Also if the container is PSKC where
should this be set?

4.9.1 and 4.9.2

In other protocol work we had both the concept of a unique request id
and the concept of the session id. If we think that DSKPP could also be
bound over non session protocols then being able to specify that the
response is the response for a specific (identified by the request Id
coming back) request can be very useful. Please see OTPS
ValidationService for an example.

4.9.5

Since there is an authentication protocol happening is
'AuthenticationDataInvalid' enough? Is there a need to distinguish
between ClientId not found and wrong one time authentication code? 

4.9.7

If more than one module is connected to the client do we need the
ability to pass the module number and slot number here? Even if
optionally?

4.9.12

ClientId, if this can represent the user, it might be a DN as in RFC
2253, hence the identifier restriction of 128 characters might be too
small.

<AuthenticationCertificate> if this is only the certificate as
transmitted in ds:KeyInfoType one does not know if the certificate was
PIN protected eg proof of user being present or not.

4.10.3

<SupportedKeyContainers> since PSKC is mandated we could make the PSKC
URI the default value in the schema

What about versioning of the PSKC, do we drive it via the URI or
explicitely? In case versioning is driven via URI should we mention it
in the text?

________________________________

Philip Hoyer 

Senior Architect - Office of CTO

ActivIdentity (UK)

109 Borough High Street

London SE1 1NL

Telephone: +44 (0) 20 7744 6248

Direct: +44 (0) 20 7744 6455

Fax: +44 (0) 20 7744 6249

Private and confidential: This message and any attachments may contain

privileged / confidential information. If you are not an intended
recipient,

you must not copy, distribute, discuss or take any action in reliance on
it.

If you have received this communication in error, please notify the
sender

and delete this message immediately.

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