Subject: Re: [KEYPROV] HOTP Algorithm Definition

From: <[email-masked]>
Date: Wed, 17 Sep 2008 13:11:21 +0300

This text probably needs to describe some additional constraints,
such as:

- Secret can be of any length as long as it's at least 16 octets (128 bits).
- ChallengeFormat MUST NOT be present.
- Time, TimeInterval, or TimeDrift MUST NOT be present.
- ResponseFormat must be DECIMAL, and Length MUST be between 6 and 9
- CheckDigit can be either TRUE or FALSE
- PINPolicy cannot be Algorithmic
- Should we also carry the HOTP throttling parameter (T) and 
  resynchronization parameter (s)? (if not, we should probably 
  explicitly say they're assumed to be server-wide configuration
  parameters, so they're not communicated here. On the other hand,
  we have TimeDrift for time-based tokens...)
 
Best regards,
Pasi

> -----Original Message-----
> From: ext Hannes Tschofenig [mailto:[email-masked]] 
> Sent: 25 August, 2008 16:56
> To: Eronen Pasi (Nokia-NRC/Helsinki); [email-masked]
> Subject: HOTP Algorithm Definition
> 
> Ming provided me with an updated version of the HOTP 
> algorithm description:
> 
> --------------------------------------------------------------------
> 
> 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
> 
>    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.
> 
>    <?xml version="1.0" encoding="UTF-8"?>
>    <KeyContainer Version="1.0"
>    xmlns="urn:ietf:params:xml:ns:keyprov:pskc:1.0">
>        <Device>
>            <DeviceInfo>
>                <Manufacturer>TokenVendorAcme</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
> 
> [email-masked] wrote:
> > Hannes Tschofenig wrote:
> >
> >   
> >> 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.
> >>     
> >
> > Thanks for working on this -- this is quite close to what I had 
> > in mind (but didn't manage to write down yet).
> >
> >   
> >> --------------------------------------------------------------
> >>
> >> 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. 
> >>     
> >
> > 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">
> >>         <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.
> >>     
> >
> > 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.
> >
> >   
> >> * 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: 
> >>     
> >
> > Yes, an example would definitely be good.
> >
> > Best regards,
> > Pasi
> >   
> 
> 
_______________________________________________
KEYPROV mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/keyprov

---

From: "Pei, Mingliang" <[email-masked]>
Date: Wed, 17 Sep 2008 18:28:35 -0700

Hi Pasi,

Thank you for the comments. I am fine with the additional constraint on
"what MUST NOT". The HOTP throttling parameters are optional at most.
When a provisioning service delivers a record to a client, it doesn't
have information for those values. I would perfer to leave it out.

- Ming 

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of [email-masked]
> Sent: Wednesday, September 17, 2008 3:11 AM
> To: [email-masked]; [email-masked]
> Subject: Re: [KEYPROV] HOTP Algorithm Definition
> 
> This text probably needs to describe some additional 
> constraints, such as:
> 
> > Ming provided me with an updated version of the HOTP algorithm 
> > description:
> > 
> > > Thanks for working on this -- this is quite close to what 
> I had in 
> > > mind (but didn't manage to write down yet).
> > >
> > >   
> > >> * I would add an example to make things clearer (instead 
> of using 
> > >> the code snippet from above).

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 23 Sep 2008 17:24:35 +0300

Regarding the "MUST NOT"s.

I would like to avoid listing what isn't present. Instead, I suggest 
that things that aren't listed are assumed not to be there. The text 
should probably say that.

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 23 Sep 2008 17:40:13 +0300

What would you write for the HOTP throttling parameter (T) and   
resynchronization parameter (s) parameters?

Pei, Mingliang wrote:
>>>       present.  The "OTP" attribute of the <Usage> MUST be 
>>>       
>> set "true"
>>     
>>>       <ResponseFormat> of the <Usage> MUST be used to 
>>>       
>> indicate the OTP
>>     
>>>       For the Data elements of a key of this algorithm, the 
>>>       
>> following
>>     
>>>>>      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">
>>>>>      indicate the current OTP counter value for the HOTP 
>>>>>           
>> algorithm.
>>

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 23 Sep 2008 17:45:28 +0300

Here is an update based on Pasi's input:

8.4.4.1.  HOTP

   Common Name:  HOTP

   Class:  OTP

   Registrant Contact:  IESG

      present.  The 'OTP' attribute of the <Usage> MUST be set "TRUE"

      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>

      The following additional constraints apply:
        - The value of the <Secret> element MUST contain key material 
with a
          lengthy of at least 16 octets (128 bits).
        - The <ResponseFormat> element MUST have the 'Format' attribute 
set to
          "DECIMAL", and the 'Length' attribute MUST be between 6 and 9.
        - The <PINPolicy> element MAY be present but the <Format> child
          element of the <PINPolicy> element cannot be set to 
"Algorithmic".

      No other attribute or element beyond the above-mentioned onces is
      assumed to be present.

      An example of this algorithm is as follows.

---

From: "Pei, Mingliang" <[email-masked]>
Date: Tue, 23 Sep 2008 08:39:28 -0700

Hi Hannes,

Thanks for the revision. The content and language for the additional
constraint look to good to me. A change on the requirement attribute
will be related to "Secret". Initially I considered it required. When we
use it in DSKPP for four-pass case, there is no secret to return from a
response while we use KeyContainer to carry only the key attributes. So
Secret will be made optional. When it is present, the value should
contain at least 16 octets etc..

- Ming

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Hannes Tschofenig
Sent: Tuesday, September 23, 2008 7:45 AM
To: [email-masked]
Cc: [email-masked]
Subject: [KEYPROV] Updated HOTP Algorithm Definition

8.4.4.1.  HOTP

   Common Name:  HOTP

   Class:  OTP

   Registrant Contact:  IESG

      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>