Subject: RE: [KEYPROV] [issue28] How to transfer initial PIN to a clientviaPSKC?

From: "Doherty, Andrea" <[email-masked]>
Date: Wed, 17 Oct 2007 20:27:32 -0400

Philip,
This looks ok except that a more complex PIN policy is needed (refer to
this comment I made to the previous version of the PSKC draft, Section
5.1.7:
"Recommend that you allow for a more complex PIN policy, esp., (a) how
the PIN is to be used in the OTP calculation (e.g., concatenated vs.
XOR's with the token code) and (b) PIN length. "

This doesn't seem to have been addressed yet based on feedback to my
review (see attached) and example below.  What is the status of this?  
Andrea

-----Original Message-----
From: Philip Hoyer [mailto:[email-masked]] 
Sent: Friday, September 28, 2007 11:48 AM
To: KEYPROV Roundup Issue Tracker; [email-masked]
Cc: Bajaj, Siddharth; Johan Rydell; M'Raihi,David
Subject: RE: [KEYPROV] [issue28] How to transfer initial PIN to a
clientviaPSKC?

Gentlemen,
Since PSKC will be used also to bulk provision from manufacturing to a
validation server and some of these devices do have a PIN pad there is
the concept of an initial PIN.

Since we have not yet defined how this initial PIN is transmitted in the
PSKC spec I would like to put forward a proposal for inclusion in the
spec for specifying the transmission of PINs.

The PIN is effectively another shared secret hence I propose to treat it
as a key in itself.

This has the advantage that we can leverage the Usage part of the schema
that can define things like length and format (alphanumeric etc). we
also can set an expiry etc. It also leverages the fact that the PIN
itself will be encrypted in transport in the same manner as other key
material.

I hence propose to extend the KeyAlgorithmType with a new type called
'userPIN' (inline with the name used in the access rules element already
present)

As an example a KeyContainer with a non encrypted HOTP key and a 4 digit
numeric PIN (please note that the value and valuedigest are just copy
and paste) ( I put the new section with NEW-> and <-NEW lines before and
after):

   <?xml version="1.0" encoding="UTF-8"?>
   <KeyContainer
   xmlns="urn:ietf:params:xml:ns:keyprov:container"
   xmlns:logo="urn:ietf:params:xml:ns:keyprov:logo"
   xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
   xsi:schemaLocation="urn:ietf:params:xml:ns:keyprov:container"
.\keyprov_pskc_schema_v1.1.xsd" version="1.1">
     <EncryptionMethod algorithm="NONE"/>
     <DigestMethod algorithm="HMAC-SHA1"></DigestMethod>
     <Device>
       <DeviceId>
         <Manufacturer>Token Manufacturer</Manufacturer>
         <SerialNo>98765432187</SerialNo>
         <Expiry>01/01/2008</Expiry>
       </DeviceId>
       <Key KeyAlgorithm="HOTP"  KeyId="98765432187">
         <Issuer>Credential Issuer</Issuer>
         <Usage>
          <ResponseFormat format="DECIMAL" length="6"/>
         </Usage>
NEW->
         <AccessRules userPIN="true"/>
<-NEW
         <FriendlyName>MyFirstToken</FriendlyName>
         <Data Name="SECRET">
           <Value>WldjTHZwRm9YTkhBRytseDMrUnc=</Value>
           <ValueDigest>WldjTHZwRm9YTkhBRytseDM=</ValueDigest>
         </Data>
         <Data Name="COUNTER">
           <Value>WldjTHZwRm9YTkhBRytseDMrUnc=</Value>
           <ValueDigest>WldjTHZwRm9YTkhBRytseDM=</ValueDigest>
         </Data>
       </Key>
NEW->
       <Key KeyAlgorithm="userPIN"  KeyId="12345678">
         <Issuer>Credential Issuer</Issuer>
         <Usage>
          <ResponseFormat format="DECIMAL" length="4"/>
         </Usage>
         <FriendlyName>MyFirstTokenInitialPIN</FriendlyName>
         <Data Name="SECRET">
           <Value>WldjTHZwRm9YTkhBRytseDMrUnc=</Value>
           <ValueDigest>WldjTHZwRm9YTkhBRytseDM=</ValueDigest>
         </Data>
       </Key>
<-NEW
     </Device>
   </KeyContainer>

Comments are welcome,

Philip

-----Original Message-----
From: Mingliang Pei [mailto:[email-masked]] 
Sent: Friday, September 21, 2007 9:58 AM
To: [email-masked]
Subject: [KEYPROV] [issue28] How to transfer initial PIN to a client
viaPSKC?

New submission from Mingliang Pei <[email-masked]>:

PSKC provies support about carrying PIN usage policy. When PIN is used,
how do 
you actually transfer the initial PIN using PSKC? Should PIN be treated
as 
another credential, for example?

----------
assignedto: mpei
messages: 71
nosy: keyprov, mpei
priority: critical
status: chatting
title: How to transfer initial PIN to a client via PSKC?

_________________________________________________________
KEYPROV Roundup Issue Tracker <[email-masked]>
<http://www.tschofenig.priv.at:8080/keyprov/issue28>
_________________________________________________________

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

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

Subject: RE: [KEYPROV] Review comments - PSKC
From: "CHANG Shuh" <[email-masked]>
To: "Doherty, Andrea" <[email-masked]>, "Pei, Mingliang" <[email-masked]>, <[email-masked]>, "Philip Hoyer" <[email-masked]>, <[email-masked]>, "CHANG Shuh" <[email-masked]>
Date: Tue, 28 Aug 2007 19:33:06 -0400

Hi Andrea,

Thanks for the great comments on the PSKC draft. The PSKC WG had an
extensive discussion today and is providing the responses shown below
under each issue.

Regards,
Shuh

> -----Original Message-----
> From: Doherty, Andrea [mailto:[email-masked]] 
> Sent: Thursday, August 16, 2007 8:50 AM
> To: Pei, Mingliang; [email-masked]; Philip Hoyer
> Subject: [KEYPROV] Review comments - PSKC
> 
> I reviewed draft-hoyer-keyprov-portable-symmetric-key-container-02.txt
> and have the following comments:
> 
> General:
> ========
> 1. Align terminology with DSKPP, esp. use of "token", 
> "credentials", "seed records", "shared secret", "secret key", 
> "attributes" throughout the document.

We acknowledge this issue, and will address it in the next revision.

> 
> 2. Add section for IANA Considerations

We will add this IANA section in this revision. (Ming's work item)

> 
> 3. Several typos found; recommend running document through 
> spell checker.

Yes, we'll do that. (Ming's work item)

> 
> Abstract:
> =========
> Is last paragraph appropriate for IETF document?

We'll remove this paragraph and add it in the Acknowledgement section.
(Ming's work item)

This work is a joint effort by the members of OATH (Initiative for Open
AuTHentication) to specify a format that can be freely distributed to
the technical community.

> 
> Section 1 (Introduction):
> =========================
> 1. It would be best if this document would be more generic to 
> application context.  Currently, it is still more "OTP" 
> focused than useful for all constituents interested in this 
> specification.

Need further discussion, and we'll address this issue in the next
revision.

> 
> 2. First sentence should read "...systems based ^^upon^^ one time..."

Yes, we'll correct that. (Ming will correct it today.)

> 
> 3. Last sentence has spelling error "wherears"

Yes, we'll correct that. (Ming will correct it today.)

> 
> Section 3.1.1 (Credential migration by end-user):
> =================================================
> Last paragraph - this is example where alignment with DSKPP 
> Key Initialization Profiles will be required (refer to Issue 
> #9 in issue tracker).

Need further discussion, and we'll address this issue in the next
revision.

> 
> Section 3.2.1 (Online provisioning...):
> =======================================
> Perhaps clarify last sentence of first paragraph ("user can 
> download more than one...").  Doesn't this capability depend 
> on whether an application has concept of a session, and how 
> the session is defined?
> Note that this capability is more of a provisioning server 
> feature, and is not applicable to DSKPP.

We'll clarify and rephrase the sentence to "a payload can contain
multiple credentials". We'll address this issue in this revision.

> 
> Section 3.2.2 (Server to server...):
> ====================================
> First sentente, "...information from ^^a^^ manufacturer".

Yes, we'll correct that. (Ming will correct it today.)

> 
> Section 5.1.4 (KeyID):
> =========================
> Perhaps add explanation here that namespace is not encoded 
> into the KeyID, but maintained as a separate attribute, e.g., 
> "Issuer".

Agree and will do it in the next revision.. (Ming's action item)

> 
> Section 5.1.7 (AccessRules):
> ============================
> Recommend that you allow for a more complex PIN policy, esp., 
> (a) how the PIN is to be used in the OTP calculation (e.g., 
> concatenated vs.
> XOR's with the token code) and (b) PIN length.

Yes, agree. Ming will open an issue in issuer tracker. Add (c) how to
transfer initial PIN value. Shuh to chat with people for some best
practice.

The issue "When PIN is used, how do you actually transfer the initial
PIN using PSKC?" needs to be further discussed. Different vendors might
have different approaches. We'd also like to solicit from the KeyProv
list members for inputs on this issue.

> 
> Section 5.1.8 (EncryptionMethod):
> =================================
> 1. Align this section with DSKPP Key Initialization Methods 
> (see Issue Tracker #9).

We'll defer this to next revision.

> 
> 2. Last paragraph - "KeyContainer" is referred to here, but 
> not previously defined.

We'll rephrase this sentence by changing word "KeyContainer" to
"payload".

> 
> Section 6 (diagram):
> ====================
> 1. Typo in diagram -- arrow between Key n and Key p should be 
> shown to the right.

Yes and will correct. (Shuh's action item)

> 
> 2. Align model represented by the diagram with Object Model in DSKPP.

This issue has been discussed in a previous PSKC conf call. The diagram
is a more clear representation of the container. On the other hand, a
more detailed object model will be genereated after the final XML schema
is finalized. (Shuh's work item)

> 
> 3. Provide note that while PSKC supports bulk provisioning of 
> keys, DSKPP does not.

This is a provisioning protocol, not a format. Therefore, it's better to
specify it in DSKPP.

> 
> Section 6.1.1 (KeyType):
> ========================
> 1. SECRET has typo "key key". 

Agree and will correct.  (Ming will correct it today.)

> 
> 2. Last paragraph on 'Value Digest' - Perhaps refer to 
> Section 5.1.8 for clarity.

Agree and will rephrase in this revision.

> 
> Section 6.1.2 (UsageType):
> ==========================
> <AlgorithmIdentifier> - replace reference to [OCRA] with URI.

We'll do that in the next revision. Deferred when URI is used.

> 
> Section 6.1.4 (DeviceIdType):
> =============================
> 1. Would be better if description were more generic; add 
> storage device as an example.

We'll rephrase it in the next revision.

> 
> 2. I recommend base64Binary as data type for SerialNo.

Will track as an issue to discuss. (Ming)

> 
> Section 6.1.5 (UserType):
> =========================
> To be consistent with the DSKPP Object Model, "UserIdType" 
> would be more consistent that "UserType".  Alternatively, 
> "ClientIDType" would be more consistent than "UserType" since 
> a user may be a software application.

We'll refer this to further study.

> 
> Section 6.1.9 (AlgorithmIdentifierType):
> ========================================
> 1. Replace [OCRA] throughout this section with appropriate URI.

We'll do that in the next revision.

> 
> 2. "The AlgorithmIdentifierType is define^^d^^ as follows"

Agree and will correct. (Ming)

> 
> Section 6.5 (KeyAlgorithmType):
> ===============================
> This type overlaps with "KeyType" in DSKPP; align.

PSKC already has a KeyType. KeyAlgorithm is another attribute layer on
top of KeyType. The KeyAlgorithmType in PSKC is different from KeyType
in DSKPP. KeyAlgorithmType is the algorithm where the key will be
applied. Therefore, we'll need to do more study on this issue to better
clarify.

> 
> Section 8.1 (Payload Confidentiality):
> ======================================
> I recommend that you identify and define each of the profiles 
> that are described at a high-level here.

We'll defer it to the next revision.

> 
> Section 8.2 (Payload Integrity):
> ================================
> "provides a mean^^s^^ to"

Agree and will correct. (Ming to change today)

> 
> Section 11 (Normative References):
> ==================================
> 1. Many of the references in the list are not normative but 
> "informative" (e.g., all of the I-D's).  I think the section 
> should either be divided in two, or simply called "References".

We need to further discuss this issue.

> 
> 2. Is [OATHRefArch] used in the document?

Will remove it.

> 
> 3. Update [DSKPP] reference to draft-ietf-keyprov-dskpp-00.txt.

Agree. (Ming to change in this revision)

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

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

---

From: "Philip Hoyer" <[email-masked]>
Date: Thu, 18 Oct 2007 12:16:14 +0200

Andrea,
You are right I have not addressed the Pin policy issue.

I would like to though. 

Since you seem to have a good idea of the requirements would you be able
to help?

I suggest we create a new type called PINPolicy that contains the data
required to be submitted.

So currently PIN usage I can think of is:
-KEY_ACCESS_CHECK (this check the pin on the device to allow access to a
key for algorithms)
-USED_IN_ALGO (used during calculation)

When you talk though about length I already have that in the <Usage>
part of the PIN 'key' see below

NEW->

Also when we talk about server verified pins in otps are we not really
talking about the otp algo or usage here?

I was wondering hence if our usage element for the otp key should be
augmented to contain and optional

<UserPIN position="APPEND/PREPEND"/>

What do you think?

Philip

-----Original Message-----
From: Doherty, Andrea [mailto:[email-masked]] 
Sent: Thursday, October 18, 2007 1:28 AM
To: Philip Hoyer; KEYPROV Roundup Issue Tracker; [email-masked]
Cc: Bajaj, Siddharth; Johan Rydell; M'Raihi,David
Subject: RE: [KEYPROV] [issue28] How to transfer initial PIN to a
clientviaPSKC?

Philip,

-----Original Message-----
From: Philip Hoyer [mailto:[email-masked]] 
Sent: Friday, September 28, 2007 11:48 AM
To: KEYPROV Roundup Issue Tracker; [email-masked]
Cc: Bajaj, Siddharth; Johan Rydell; M'Raihi,David
Subject: RE: [KEYPROV] [issue28] How to transfer initial PIN to a
clientviaPSKC?

Gentlemen,

Comments are welcome,

Philip

-----Original Message-----
From: Mingliang Pei [mailto:[email-masked]] 
Sent: Friday, September 21, 2007 9:58 AM
To: [email-masked]
Subject: [KEYPROV] [issue28] How to transfer initial PIN to a client
viaPSKC?

----------
assignedto: mpei
messages: 71
nosy: keyprov, mpei
priority: critical
status: chatting