Subject: [KEYPROV] PSKC -- Additional Information regarding Algorithms

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 11 Aug 2008 20:37:31 +0300

At the last IETF meeting we had a discussion on how to provide 
additional information in the PSKC document to improve interoperability.
Pasi sent a mail to the list about this issue today.

Ming provided some additional information on how this could look like 
based on one algorithm, namely HOTP.

--------------------------------------------------------------

8.4.4.1.  HOTP

   Common Name:  HOTP

   Class:  OTP

   URI:  http://www.ietf.org/keyprov/pskc#hotp

   Algorithm Definition:  http://www.ietf.org/rfc/rfc4226.txt

   Identifier Definition  (this RFC)

   Registrant Contact:  IESG

   Required XML attributes for a Key element:

     For a key of this algorithm, the Usage element must be present. 
     The "OTP" attribute of the Usage must be set "true". The
ResponseFormat 
     must be used to indicate the OTP length and the value format. The
Usage 
     element for such a Key element should look like the following.

      <Usage OTP="true">
        <ResponseFormat Length="8" Format="DECIMAL"/>
      </Usage>

     One of the data type in Key/Data element should be <Counter> to
indicate 
     the current OTP counter value for the HOTP algorithm.

--------------------------------------------------------------

This is a first step but not precise enough. What is missing is: 
* Are these the only values that are allowed to be set? I would indicate this. 
With this specific algorithm I believe there isn't a lot of freedom. 
* Why isn't the counter mandatory? 
* I am missing RFC 2119 language in the above exchange. 
* I would add an example to make things clearer (instead of using the code snippet from above).
The example from Section 11.1 would work here: 

   <?xml version="1.0" encoding="UTF-8"?>
   <KeyContainer Version="1.0"
   xmlns="urn:ietf:params:xml:ns:keyprov:pskc:1.0">
       <Device>
           <DeviceInfo>
               <Manufacturer>Manufacturer</Manufacturer>
               <SerialNo>987654321</SerialNo>
           </DeviceInfo>
           <Key KeyAlgorithm="http://www.ietf.org/keyprov/pskc#hotp"
           KeyId="987654321">
               <Issuer>Issuer</Issuer>
               <Usage OTP="true">
                   <ResponseFormat Length="8"
                   Format="DECIMAL"/>
               </Usage>
               <Data>
                   <Secret>
                       <PlainValue>
                       MTIzNDU2Nzg5MDEyMzQ1Njc4OTA=
                       </PlainValue>
                   </Secret>
                   <Counter>
                       <PlainValue>0</PlainValue>
                   </Counter>
               </Data>
           </Key>
       </Device>
   </KeyContainer>

Ciao
Hannes

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

---

From: <[email-masked]>
Date: Mon, 25 Aug 2008 15:41:09 +0300

Hannes Tschofenig wrote:

> additional information in the PSKC document to improve
> interoperability.  Pasi sent a mail to the list about this issue
> today.
> 
> Ming provided some additional information on how this could look
> like based on one algorithm, namely HOTP.

Thanks for working on this -- this is quite close to what I had 
in mind (but didn't manage to write down yet).

>      must be used to indicate the OTP length and the value format. 

Not all ResponseFormat values make sense for HOTP; that should
probably be described.

>      The Usage element for such a Key element should look like the
>      following.
> 
>       <Usage OTP="true">
>      indicate the current OTP counter value for the HOTP algorithm.
>
> * Are these the only values that are allowed to be set? I would
> indicate this.  With this specific algorithm I believe there isn't a
> lot of freedom.

Agree, the text should also say what attributes don't make sense here.

Additionally, it should something about KeyData (it seems HOTP
needs/accepts a single key of arbitrary length, but that isn't the case
for all algorithms), and PINPolicy (not all values make sense for HOTP).

> * Why isn't the counter mandatory? 

Good question; probably needs clarification.

> * I am missing RFC 2119 language in the above exchange. 

Yes.

> The example from Section 11.1 would work here: 

Yes, an example would definitely be good.

Best regards,
Pasi

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 25 Aug 2008 16:55:46 +0300

Ming provided me with an updated version of the HOTP algorithm description:

--------------------------------------------------------------------

8.4.4.1.  HOTP

   Common Name:  HOTP

   Class:  OTP

   Identifier Definition:  (this RFC)

   Registrant Contact:  IESG

   Profile of XML attributes and subelements of the Key entity:

      For a Key of this algorithm, the <Usage> subelements MUST be
      present.  The "OTP" attribute of the <Usage> MUST be set "true"
      and it MUST be the only attribute set.  The element
      <ResponseFormat> of the <Usage> MUST be used to indicate the OTP
      length and the value format.

      For the Data elements of a key of this algorithm, the following
      subelements MUST be present in either the Key element itself or an
      commonly shared KeyProperties element.

      *  Secret

      *  Counter

      An example of the Key of this algorithm is as follows.

               <Manufacturer>TokenVendorAcme</Manufacturer>

--------------------------------------------------------------------

Ciao
Hannes