[16933] in Kerberos_V5_Development
Re: OTP, deployability.
daemon@ATHENA.MIT.EDU (Nico Williams)
Fri Jun 17 18:06:07 2011
MIME-Version: 1.0
In-Reply-To: <4DFBBCF7.3030808@redhat.com>
Date: Fri, 17 Jun 2011 17:06:03 -0500
Message-ID: <BANLkTikssw7riU0fcACaqcipje2YN_z=GQ@mail.gmail.com>
From: Nico Williams <nico@cryptonector.com>
To: dpal@redhat.com
Cc: krbdev@mit.edu
Content-Type: text/plain; charset="utf-8"
Errors-To: krbdev-bounces@mit.edu
Content-Transfer-Encoding: 8bit
On Fri, Jun 17, 2011 at 3:45 PM, Dmitri Pal <dpal@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 ownAPI, 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 vendorson-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--
_______________________________________________krbdev mailing list krbdev@mit.eduhttps://mailman.mit.edu/mailman/listinfo/krbdev
