Subject: Re: [KEYPROV] HOTP Algorithm Definition

From: "Pei, Mingliang" <[email-masked]>
Date: Mon, 3 Nov 2008 18:14:17 -0800

Hi Hannes,

I just digged out this email and send my thoughts on this.

The two parameters are related to server side validation policy or
configuration. The client doesn't need to know it. Often such parameters
are not associated with individual token records during bulk migration.
So I prefer to not add them. Following our general rule, we don't need
to indicate what "MUST NOT".

On the other hand, token record bulk export for time based tokens may
involve the "current time center" or the detected clock drift as far
known to the authentication server. While the "TimeDrift" element was
reserved to indicate the possible max clock drift for a token per day
(really TIME_DRIFT_PER_DAY, something like "TimeDrifted" could be
introduced. Or we can leave it to individual service provider to define
since the key data elements are extensible.

Feedbacks on this are appreciated.

Thanks,

- Ming

> -----Original Message-----
> From: Hannes Tschofenig [mailto:[email-masked]] 
> Sent: Tuesday, September 23, 2008 7:40 AM
> To: Pei, Mingliang
> Cc: [email-masked]; [email-masked]
> Subject: Re: [KEYPROV] HOTP Algorithm Definition
> 
> What would you write for the HOTP throttling parameter (T) and   
> resynchronization parameter (s) parameters?
> 
> Pei, Mingliang wrote:
> > 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
> >
> >   
> >> -----Original Message-----
> >> 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:
> >>
> >> - 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
> >>
> >>     
> 
> 
_______________________________________________
KEYPROV mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/keyprov