On 08/03/2011 01:56 PM, Simo Sorce wrote:
> On Wed, 2011-08-03 at 13:46 -0400, Stephen Gallagher wrote:
>> On Wed, 2011-08-03 at 13:41 -0400, Ian Stokes-Rees wrote:
>>> On 8/3/11 1:02 PM, Stephen Gallagher wrote:
>>>> So I guess what I'm saying is not "Don't use centrally managed key
>>>> storage", but rather "If you use the key anywhere but in this
>>>> administrative domain, do not put it in centrally-managed storage
>>>> that anyone but you can ever gain access to it".
>>> Yes, I appreciate the distinction you raise. Regarding your last
>>> comment quoted above, to the best of my knowledge that is impossible.
>>> I regularly have discussions with people saying "an administrator
>>> could always do X,Y and Z to access your supposedly private data" --
>>> if there are ways in which I could be wrong about that, I'd love to
>>> know them. Otherwise I believe that the key risks from a centralized
>>> keystore are:
>>> * ease of compromise by an unscrupulous administrator
>>> * extent of compromise if attacker gains administrative privs to
>>> central keystore (although it sounds like the RH DRM system could
>>> significantly reduce that)
>>> * risk of compromise due to security vulnerabilities in central
>>> keystore software
>>> I think the general consensus is that you are always exposed to some
>>> degree of risk, and it is necessary to evaluate the risks versus the
>>> benefits. There are some lovely lakes in northern Maine where you can
>>> probably use your laptop without too much risk of compromised privacy,
>>> or closer to home, I'm sure most of us can remember a day when we got
>>> lots of useful work done on a computer with no network connection and
>>> were excited when we got one new piece of software every few months.
>>> In my risk/benefit world, a centralized keystore would be really
>>> And for the record, if any one of the computers I use is compromised
>>> with a keyboard scanner or theft of my private ssh or X.509 keys, then
>>> I'm in a whole world of pain, and not a small amount of inconvenience
>>> (and risk of malicious attacks) to the various systems I regularly
>>> access. Best I can tell, that isn't too different from most people in
>>> my situation, and short of that nice cabin in Maine, is simply the
>>> reality (risk) of the kind of work I do, and the people I do it for.
>> Well, there exist central storage approaches that don't allow even the
>> local admin access to the data. The trade-off of course is that they
>> can't reinstate your access if you forget the password.
>> In other words, you can set a password that is used as a symmetric key
>> for encrypting your data in the central store. It's still central and
>> can be retrieved from anywhere, but only you know how to read it.
> In these situations to allow recovery you can have all data encrypted a
> second time with a central store public key. But the corresponding
> private key is not stored in a place accessible online and gaining
> access to the means to recover keys is subject to logging on a
> specialized system which audits everything you do and notifies all
> interested parties automatically when you access anyone's keys.
> That can be done but it is expensive, something we can plan for a the
> future, but not something we can do in the short term.
Simo and Stephen,
I do not think we would be able to design this right here an right now.
It is a complex problem. I think we should design the solution when time
comes (this fall) to be secure but allow people to loosen the security
if the environment they work in allows it.
For example we never know anything about the physical security of the
deployment thus we always assume worst. But it does not mean that the
environment does not have other means to secure access and that IPA has
to be the lonely soldier. IMO it is up to the deployment to avoid our
tight security recommendations and implement less secure approaches. It
is all a trade off that should be evaluated in a specific environment by
people in charge. We should educate about best practices but not enforce
as there are reasons not to follow them.
Sr. Engineering Manager IPA project,
Red Hat Inc.
Looking to carve out IT costs?
Freeipa-users mailing list