Hi Adam, I apologize if I came across as disrespectful. I was becoming frustrated that what I perceived as a valid concern was seemingly being ignored, but I recognize that there is no excuse for addressing you in a manner that I would not myself wish to be treated. I will do better going forward.
Thanks, Maru ps: Thank you for the reminder, Joe! On 2012-08-02, at 1: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. > > - joe > > On Aug 1, 2012, at 8:05 PM, Maru Newby <mne...@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. >> >> 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@lists.launchpad.net >>>> Unsubscribe : https://launchpad.net/~openstack >>>> More help : https://help.launchpad.net/ListHelp >>> >>> _______________________________________________ >>> Mailing list: https://launchpad.net/~openstack >>> Post to : openstack@lists.launchpad.net >>> Unsubscribe : https://launchpad.net/~openstack >>> More help : https://help.launchpad.net/ListHelp >> >> _______________________________________________ >> Mailing list: https://launchpad.net/~openstack >> Post to : openstack@lists.launchpad.net >> Unsubscribe : https://launchpad.net/~openstack >> More help : https://help.launchpad.net/ListHelp
_______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
