OTP, deployability.

Nico Williams nico at cryptonector.com
Fri Jun 17 18:06:03 EDT 2011


On Fri, Jun 17, 2011 at 3:45 PM, Dmitri Pal <dpal at redhat.com> wrote:
> On 06/17/2011 04:06 PM, Roland C. Dowdeswell wrote:
>> On Fri, Jun 17, 2011 at 02:49:30PM -0400, Dmitri Pal wrote:
>>> It is not too hard. It is risky.
>>> IMO it is a bad security practice to expose the OTPs in an interface.
>> I disagree.  I do not think that it is bad security practice to
>> allow the KDC to read user's current and potentially future OTPs.
>
> KDC sure, the challenge is to enforce that it is KDC only.
> It can be done, but it is hard to drive vendors into it without the well
> thought through standards.

That's no challenge at all.

Pick a secure transport.  Key it.  Setup appropriate ACLs.  Done.

> So what are our options?
>
> 1) Create a standard for the exchange so that vendors can implement the
> interface. Paves a way but does not add a lot of incentive.

We don't need a standard.  It'd be OK if each vendor had their own
API, as long as they have one at all.

> 2) Develop and OTP server using open standards (HOTP/TOTP) that would be
> integrated with KDC.

(2) is the simplest because it doesn't require getting any vendors
on-board.  It does require using tokens that support standard OTPs,
but those exist, and they're cheap too.

> Both options go to the same goal and IMO can be executed in parallel. I
> suspect the first one would take more time than the second.

(1) could be done in no time, if the vendors cared.

It sounds like we all agree, roughly, now.

Nico
--




More information about the krbdev mailing list