Open Stack

On 08/02/2012 01:56 AM, Joseph Heck wrote:
> Hey Maru,
>
> I think you're putting too many words in Adam's mouth here. First, 
> Adam didnt assert is wasnt valuable, useful, or nessecary - simply 
> that it wasnt in the first cut and not in the list that we agreed was 
> critically essential to an initial implementation. As you noted, its a 
> complex and somewhat tricky issue to get right.
>
> There's always room for more participation to correct the flaws you 
> see in the existing system - the beauty of open source. I would love 
> to see continued work on the signing and revocation work to drive in 
> these features that mean so much to you.  I'd be happy to open a 
> blueprint if you can stand behind it, define what you think it 
> required, and commit to the work to implement that revocation mechanism.
>
> Implying negative emotions on Adam's part when he's been one driving 
> the implementation and doing the work is simply inappropriate. Please 
> consider the blueprint route, definition of a viable solution, and 
> work to make it happen instead of name calling and asserting how the 
> developers doing the work are screwing up.

Thanks for the support Joe.  I don't think Maru was being too harsh.  So 
long as he doesn't start calling me "Sir" as that is always an followed 
by "you are making a scene."
>
> - joe
>
> On Aug 1, 2012, at 8:05 PM, Maru Newby <mnewby at internap.com 
> <mailto:mnewby at internap.com>> wrote:
>> Hi Adam,
>>
>> I apologize if my questions were answered before.  I wasn't aware 
>> that what I perceive as a very serious security concern was openly 
>> discussed.  The arguments against revocation support, as you've 
>> described them, seem to be:
>>
>>  - it's complicated/messy/expensive to implement and/or execute
>>  - Kerberos doesn't need it, so why would we?
>>
>> I'm not sure why either of these arguments would justify the 
>> potential security hole that a lack of revocation represents, but I 
>> suppose a 'short enough' token lifespan could minimize that hole. 
>>  But how short a span are you suggesting as being acceptable?
>>
>> The delay between when a user's access permissions change (whether 
>> roles, password or even account deactivation) and when the ticket 
>> reflects that change is my concern.  The default in Keystone has been 
>> 24h, which is clearly too long.  Something on the order of 5 minutes 
>> would be ideal, but then ticket issuance could become the bottleneck. 
>>  Validity that's much longer could be a real problem, though.  Maybe 
>> not at the cloud administration level, but for a given project I can 
>> imagine someone being fired and their access being revoked.  How long 
>> is an acceptable period for that ticket to still be valid?  How much 
>> damage could be done by someone who should no longer have access to 
>> an account if their access cannot be revoked, by anyone, at all?
>>
>> I'm hearing that you, as the implementer of this feature, don't 
>> consider the lack of revocation to be an issue.  What am I missing? 
>>  Is support for revocation so repugnant that the potential security 
>> hole is preferable?  I can see that from a developer's perspective, 
>> but I don't understand why someone deploying Keystone wouldn't avoid 
>> PKI tokens until revocation support became available.
I think you have valid concerns.  Realistically, I think 5 minutes is 
too short,  and for many operations, 24 hours would be the right 
granularity.  However,  The timespan of the tokens is configurable, and 
the policy of the deploying organization should dictate.

Remember, this is the administrative interface for virtual machines, and 
not the applications running in them.  Removing someone from access to 
creating/rebooting/destroying virtual machines is a much more deliberate 
decision than banning someone from a public forum.  Aside from someone 
getting fired, I am not sure how essential it is that we have rapid 
revocation of tokens.  And firing someone is usually part of the whole 
"escort from the building"  routine.

So, let me put the onus on you:  make the argument for rapid revocation 
of tokens.


>>
>> Thanks,
>>
>>
>> Maru
>>
>>
>> On 2012-08-01, at 9:47 PM, Adam Young wrote:
>>
>>> On 08/01/2012 09:19 PM, Maru Newby wrote:
>>>> I see that support for PKI Signed Tokens has been added to Keystone 
>>>> without support for token revocation.  I tried to raise this issue 
>>>> on the bug report:
>>>>
>>>> https://bugs.launchpad.net/keystone/+bug/1003962/comments/4
>>>>
>>>> And the review:
>>>>
>>>> https://review.openstack.org/#/c/7754/
>>>>
>>>> I'm curious as to whether anybody shares my concern and if there is 
>>>> a specific reason why nobody responded to my question as to why 
>>>> revocation is not required for this new token scheme.   Anybody?
>>>
>>> It was discussed back when I wrote the Blueprint.  While it is 
>>> possible to do revocations with PKI,  it is expensive and requires a 
>>> lot of extra checking.  Revocation is a policy decision, and the 
>>> assumption is that people that are going to use PKI tokens are 
>>> comfortable with out revocation.  Kerberos service tickets have the 
>>> same limitation, and Kerberos has been in deployment that way for 
>>> close to 25 years.
>>>
>>> Assuming that PKI ticket lifespan is short enough,  revocation 
>>> should not be required.  What will be tricky is to balance the needs 
>>> of long lived tokens (delayed operations, long running operations) 
>>> against the needs for reasonable token timeout.
>>>
>>> PKI Token revocation would look like CRLs in the Certificate world.  
>>> While they are used, they are clunky.  Each time a token gets 
>>> revoked, a blast message would have to go out to all registered 
>>> parties informing them of the revocation.  Keystone does not yet 
>>> have a message queue interface, so doing that is prohibitive in the 
>>> first implementation.
>>>
>>> Note that users can get disabled, and token chaining will no longer 
>>> work:  you won't be able to use a token to get a new token from 
>>> Keystone.
>>>
>>>
>>>>
>>>> Thanks,
>>>>
>>>>
>>>> Maru
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Mailing list:https://launchpad.net/~openstack
>>>> Post to     :openstack at lists.launchpad.net
>>>> Unsubscribe :https://launchpad.net/~openstack
>>>> More help   :https://help.launchpad.net/ListHelp
>>>
>>> _______________________________________________
>>> Mailing list: https://launchpad.net/~openstack 
>>> <https://launchpad.net/%7Eopenstack>
>>> Post to     : openstack at lists.launchpad.net 
>>> <mailto:openstack at lists.launchpad.net>
>>> Unsubscribe : https://launchpad.net/~openstack 
>>> <https://launchpad.net/%7Eopenstack>
>>> More help   : https://help.launchpad.net/ListHelp
>>
>> _______________________________________________
>> Mailing list: https://launchpad.net/~openstack 
>> <https://launchpad.net/%7Eopenstack>
>> Post to     : openstack at lists.launchpad.net 
>> <mailto:openstack at lists.launchpad.net>
>> Unsubscribe : https://launchpad.net/~openstack 
>> <https://launchpad.net/%7Eopenstack>
>> More help   : https://help.launchpad.net/ListHelp

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20120802/8f516b51/attachment.html>