OTP, deployability.

Dmitri Pal dpal at redhat.com
Fri Jun 17 18:52:26 EDT 2011


On 06/17/2011 06:06 PM, Nico Williams wrote:
> 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.

I know. May be I am too paranoid but this sounds like saying:
"Let us do an interface to fetch keys from HSM. Sure we can protect it!
Pick a secure transport. Key it. Setup appropriate ACLs. Done."
But it just does not sound right...
But anyways... no need to continue discussing this part. Assume I am
convinced.
>> 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.

There is no incentive for them to have one. I am talking about standard
more as a driver to boost interest and participation rather than
expecting each to solve the problem their own way. mIght work for some
vendors.

>> 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.

Right.

>> 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.
>
But they do not.

> It sounds like we all agree, roughly, now.

Sure. So what is next?

> Nico
> --


-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager IPA project,
Red Hat Inc.


-------------------------------
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/






More information about the krbdev mailing list