[Freeipa-devel] [PATCH] 531-541 OTP UI

Petr Vobornik pvoborni at redhat.com
Wed Feb 26 11:57:34 UTC 2014


On 26.2.2014 01:55, Dmitri Pal wrote:
> On 02/24/2014 10:21 AM, Nathaniel McCallum wrote:
>> On Mon, 2014-02-24 at 15:48 +0100, Petr Vobornik wrote:
>>> On 24.2.2014 15:31, Nathaniel McCallum wrote:
>>>> On Mon, 2014-02-24 at 11:04 +0100, Petr Vobornik wrote:
>>>>> On 21.2.2014 20:00, Nathaniel McCallum wrote:
>>>>>> Is it possible to do something more intelligent for the key and date
>>>>>> fields in the add-token UI?
>>>>>>
>>>>>> Date fields are currently just a text box. Is there any sort of
>>>>>> calendar
>>>>>> we could use here? If not, I'm still unsure of what the format
>>>>>> should be
>>>>>> for this field.
>>>>> It's the format you chose :), try to fill it in CLI, you will have the
>>>>> same proble. From API level it's just string, from LDAP it's
>>>>> generalized
>>>>> time.
>>>> Is there a better option? I'm open to suggestions.
>>> As I mentioned below, it's being implemented. The datetime patches will
>>> be send separately. The core OTP UI patches should not be blocked by
>>> them.
>>>
>>>>> I've an UI patch prepared where you can write it in ISO format, with a
>>>>> validator attached to it, so user will be noticed about the format,
>>>>> but
>>>>> it's waiting for:
>>>>> https://www.redhat.com/archives/freeipa-devel/2014-January/msg00057.html
>>>>>
>>>>> https://www.redhat.com/archives/freeipa-devel/2014-January/msg00060.html
>>>>>
>>>>>
>>>>>> The key field should probably have a note indicating that it is
>>>>>> Base32
>>>>>> encoding. It would also be nice to restrict the input to Base32
>>>>>> characters. Maybe even automatic case correction...
>>>>> Actually I think it doesn't help much. Show me a person who can write
>>>>> base32 encoded string.... But I agree that a validator with some regex
>>>>> to limit the chars and a note that it should be base32 string is
>>>>> better.
>>>>> The question is what's the purpose of this field from user
>>>>> perspective.
>>>>> Is a human being suppose to fill it or is it meant to be only
>>>>> filled by
>>>>> some provisioning systems? In UI it's just as a backup?
>>>>>
>>>>> If there is a use case where user is suppose to choose the key, it
>>>>> would
>>>>> be better to fill the key and convert it to base32 string on a server.
>>>> I can't think of any case where a user would use the key field.
>>>>
>>>> However, there are at least two important cases where an admin would do
>>>> this:
>>>> 1. Hardware tokens
>>>> 2. Transferring OATH (TOTP/HOTP) tokens from another system
>>>>
>>>> Nathaniel
>>>>
>>> What is the input format for these two cases? Is it base32 so admin can
>>> enter it into UI or is it plain text so he has to use different tool to
>>> encode it to base32 and then fill into UI?
>> In both of the above cases, I suspect the predominant use will be
>> scripts written to take a token store and import the tokens. This is
>> mostly a non-UI case.
>>
>> RFC 6030 uses Base64 for unencrypted tokens. Base32 is also in wide use.
>> This is largely because, with fewer characters and no case-sensitivity,
>> Base32 is easier to type. I don't know of any other encodings in wide
>> use.
>>
>> It would be nice to support both of them, but I'm not sure how this is
>> possible. Suggestions are welcome.
>
> I do not think we should allow typing the key (and other attributes)
> manually.
> We should rather ask user to import a token or tokens from the XML file
> that uses RFC6030.
> There are vendors of the hardware tokens that actually using it to
> distribute the tokens.
>
> Here are the examples
> http://www.gooze.eu/howto/oath-otp-tokens-howto/seed-codes-sample-files
>
> Please click around the site for more info.
>

This is one vendor. Do we have information that the other ones (or just 
the major ones) use the XML PSKC schema from RFC6030 as well? If that's 
the case, we have enough information for implementing otp-import (design 
page says that we don't have enough info).

Back to UI. The UI might be useful if the admin has the values in 
different form than XML data, i.e., printed on a paper. Having the UI 
doesn't do any harm, right?

If vendors mostly use base64 keys, adding only base32 support in our API 
doesn't make much sense. IMO it actually adds more work because you have 
to convert it first.

Anyway: NACK for the patch because it shows totp/hotp switch in 
selfservice without possibility to define other hotp specifics. I'll 
remove it so there will be only totp in self-service (just token 
name+description).
-- 
Petr Vobornik




More information about the Freeipa-devel mailing list