[16930] in Kerberos_V5_Development
Re: OTP, deployability.
daemon@ATHENA.MIT.EDU (Nico Williams)
Fri Jun 17 16:27:50 2011
MIME-Version: 1.0
In-Reply-To: <20110617200610.GL12572@mournblade.imrryr.org>
Date: Fri, 17 Jun 2011 15:27:41 -0500
Message-ID: <BANLkTim23QTRCeuGBLceSkb73MJAh3mBSw@mail.gmail.com>
From: Nico Williams <nico@cryptonector.com>
To: "Roland C. Dowdeswell" <elric@imrryr.org>
Cc: Dmitri Pal <dpal@redhat.com>, 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:06 PM, Roland C. Dowdeswell <elric@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 decadesof experience in doing that.
It's *local* security that's hard. That's why so many of us work onnetwork security: it's like the story of the drunk looking for hiskeys 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 Dmitrimight not be familiar enough with Kerberos to have come to the sameconclusion as the rest of us regarding your proposal, and Dmitri can'trepresent all of RH. :)
Nico--
_______________________________________________krbdev mailing list krbdev@mit.eduhttps://mailman.mit.edu/mailman/listinfo/krbdev
