OTP, deployability.

[Nico Williams]

On Fri, Jun 17, 2011 at 3:06 PM, Roland C. Dowdeswell <elric at imrryr.org> 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.
> After all, the KDC can mint tickets for the user without bothering
> to check with the OTP server at all.  It is perfectly reasonable
> to consider the OTP system to be a subcomponent of the KDC
> infrastructure and allow information to flow in the correct direction:
> that is from lower risk systems (the OTP servers) to higher risk
> systems (the KDCs).  Whether the components of the KDC infrastructure
> physically reside on the same machine is something that is best
> left up to the customers to decide because they are likely to have
> a little more knowledge of their environment and requirements than
> the vendor.

+1

> There are plenty of ways to construct reasonably secure ways to
> allow this to happen.  It's a cop-out to say that it is not possible
> to securely transmit information from point A to point B.  That

+1

Securing network communications is relatively easy -- we have decades
of experience in doing that.

It's *local* security that's hard.  That's why so many of us work on
network security: it's like the story of the drunk looking for his
keys under the street light -- we do this because it's easy.

> is, unless you are working for a company that does not specialise
> in computer security.

Is that a knock on RH?  That would not be fair to RH, since Dmitri
might not be familiar enough with Kerberos to have come to the same
conclusion as the rest of us regarding your proposal, and Dmitri can't
represent all of RH.  :)

Nico
--