Subject: [KEYPROV] RE: Comments on DSKPP and alignment issues

From: "Pei, Mingliang" <[email-masked]>
Date: Mon, 26 Nov 2007 14:47:25 -0800

We have resolved most alignment issues between DSKPP and PSKC. There are
a few minor issues to resolve.
 
1. KeyType as an element in DSKPP vs. KeyType as a type for key in PSKC.
 
Proposal:
 
Change DSKPP KeyType to be KeyAlgorithm. Notice that the actual value of
KeyType matches the attribute KeyAlgorithm of PSKC KeyType.
 
<xs:element name="KeyType"
  type="dskpp:AlgorithmType"/>
 
<KeyProvClientHello ...>
 <SupportedKeyTypes>
  <Algorithm>http://www.ietf.org/keyprov/pskc#HOTP</Algorithm>
 
<Algorithm>http://www.rsa.com/rsalabs/otps/schemas/2005/09/otps-wst#Secu
rID-AES</Algorithm>
 </SupportedKeyTypes>
 
<KeyProvServerHello ...>
  <KeyAlgorithm>http://www.ietf.org/keyprov/pskc#HOTP</KeyAlgorithm>
  <.../>
<KeyProvServerHello>
 
become
 
<xs:element name="KeyAlgorithm"
  type="dskpp:AlgorithmType"/>
 
<KeyProvClientHello ...>
 <SupportedKeyAlgorithms>
  <Algorithm>http://www.ietf.org/keyprov/pskc#HOTP</Algorithm>
 
<Algorithm>http://www.rsa.com/rsalabs/otps/schemas/2005/09/otps-wst#Secu
rID-AES</Algorithm>
 </SupportedKeyAlgorithms>
 
Comments?
 
2. (new) For element name convention about IDs, DSKPP currently uses
"xxxID" (e.g. KeyID) while PSKC uses "xxxId" (e.g., KeyId). Which style
do you vote for?
 
Please see inline for status on the others.
 
Thanks,
 
- Ming

________________________________

	From: Philip Hoyer [mailto:[email-masked]] 
	Sent: Thursday, September 20, 2007 12:26 PM
	To: Doherty, Andrea; Pei, Mingliang; Salah; [email-masked]
	Cc: Shuh
	Subject: Comments on DSKPP and alignment issues

	Hi Andrea and others,

	Please find below an analysis for alignment points between DSKPP
and PSKC and a long overdue comment on the draft itself.

	Please review and then I would like to agree on what we should
tackle for the next two releases of the respective specs, end of this
month and end of next month.

	Feel free to post to the mailing list, I was not sure that I
immediately should.

	Philip

	Alignment points

	1) KeyType

	DSKPP

	The type of symmetric cryptographic methods for which the key
will be used (e.g., OATH HOTP or RSA SecurID authentication, AES
encryption, etc.)

	PSKC

	The KeyType represents the key entity in the KeyContainer.

	MP: TBD

	2) Key Container

	DSKPP

	Key Container        

	An object that encapsulates a symmetric key and its
configuration data

	(DSKPP Key Container is effectively the PSKC KeyType)

	PSKC

	The KeyContainerType represents the key container entity.  A
Container MAY contain more than one Device entity; each Device entity
MAY contain more than one Key entity.

	MP: PSKC KeyContainer is used.

	3) VersionType

	DSKPP:

	<xs:simpleType name="VersionType">

	     <xs:restriction base="xs:string">

	       <xs:pattern value="\d{1,2}\.\d{1,3}"/>

	     </xs:restriction>

	   </xs:simpleType>

	PSKC

	<simpleType name="VersionType" final="restriction">

	                        <restriction base="string">

	                                    <pattern
value="\d{1,9}\.\d{0,9}"/>

	                        </restriction>

	</simpleType>

	MP: DSKPP version type is adopted.

	4) AlgorithmsType

	MP: Use URI in both DSKPP and PSKC.

	5) KeyID

	DSKPP base64binary

	PSKC string

	MP: Use "string" type.

	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

---

From: "Doherty, Andrea" <[email-masked]>
Date: Tue, 27 Nov 2007 10:43:23 -0500

Ming, regarding #1 (KeyType), below, it would be good to get feedback
from others.  KeyType is more commonly used, and I would argue that it
would be clearer to implementers than KeyAlgorithm in the context that
we are using it.  
 
For those who missed this before, here is a previous email exchange that
Ming and I had on this topic: 
 
In a previous email exchange, I raised the point that - 

	            #7, KeyType: A Google search was done and there were
610,000 hits on keyType.  However, there were only 9 hits on
keyAlgorithmType, of which 7 are from PSKC.  keyAlgorithmType is a
common notation in several APIs including PKCS#11.  What other aspects
of keyTypes are there than the algorithm?  For EncryptionAlgorithm,
etc., one cannot just say "Encryption", but possibly could say
"EncryptionMechanism".  If that was the case, then wouldn't it make more
sense to say keyMechanismType?
	
	        *  As a guiding principal, I think that it is important
that KEYPROV docs rely on commonly used, rather than homegrown, types.

Ming responded that - 

	    The google search result is interesting about KeyType.
However, the numbers cannot justify the choice though. One reason is
that KeyType itself can have multiple meanings while KeyAlgorithm is
more specific to our purpose.
	
	* Key may be database primary key; so KeyType was used by some
for database index reference.
	* Key can be also used for a hash table. Then key type for a
hash table has more reference.
	* Our particular refernece is for a "secret".
	
	In the first page of the google search result, the first two /
PKSC11 class KeyType is the main one related. The rest is mostly not
relevant to our meaning of key.
	Anyway, I do see your point, and like to get broad opinions.
KeyType is intuitive to mean what kind of key, and I don't see strong
reasons. KeyAlgorithm is more specific to algorithms associated with a
key. We have an issue that KeyType is used differently in DSKPP and PSKC
that we need to resolve for a best fit. In PSKC, KeyType is a type to
define a Key. Key has an attribute called KeyAlgorithm. If we look at
JCE, there is definition of Key class. The attribute is algorithm, not a
type. So it looks natural. In DSKPP, KeyType is an element instead. Let
us try to not use the same word in two types of keyprov docs. In DSKPP,
KeyType is actually a AlgorithmType. See ServerHello definition below.

	  <xs:complexType name="ServerHelloPDU">...
	         <xs:sequence minOccurs="0">
	           <xs:element name="KeyType"
	             type="dskpp:AlgorithmType"/>
	           <xs:element name="EncryptionAlgorithm"
	             type="dskpp:AlgorithmType"/>
	           <xs:element name="MacAlgorithm"
	             type="dskpp:AlgorithmType"/>
	
	For this reason, it seems to be also natural to change KeyType
to KeyAlgorithm, similar to the existing EncryptionAlgorithm in the same
block of definition about ServerHello. I am open for another better
choice.

Andrea

From: Pei, Mingliang [mailto:[email-masked]] 
Sent: Monday, November 26, 2007 5:47 PM
To: Philip Hoyer; Doherty, Andrea; Salah; [email-masked]
Cc: Shuh; [email-masked]
Subject: RE: Comments on DSKPP and alignment issues

 
Proposal:

 
<KeyProvClientHello ...>
 <SupportedKeyTypes>

<KeyProvServerHello ...>
 
become

<KeyProvClientHello ...>
 <SupportedKeyAlgorithms>

Comments?

 
Thanks,
 
- Ming

	

	Hi Andrea and others,

	Philip

	Alignment points

	1) KeyType

	DSKPP

	PSKC

	MP: TBD

	2) Key Container

	DSKPP

	Key Container        

	PSKC

	3) VersionType

	DSKPP:

	     </xs:restriction>

	   </xs:simpleType>

	PSKC

	                                    <pattern

	                        </restriction>

	</simpleType>

	4) AlgorithmsType

	5) KeyID

	DSKPP base64binary

	PSKC string

	MP: Use "string" type.

	COMMENTS:

	4.2.2

	Two Pass DSKPP

	4.5.2 

	 

	4.8.1.1

	 

	4.8.2.1

	 

	4.9.1 and 4.9.2

	4.9.5

	4.9.7

	4.9.12

	4.10.3

	 

	 

	Philip Hoyer 

	ActivIdentity (UK)

	109 Borough High Street

	London SE1 1NL