18:00:16 <bdpayne> #startmeeting OpenStack Security Group
18:00:17 <openstack> Meeting started Thu May 16 18:00:16 2013 UTC.  The chair is bdpayne. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:00:18 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
18:00:20 <openstack> The meeting name has been set to 'openstack_security_group'
18:00:46 <bdpayne> hi everyone
18:00:52 <malini1> Greetings
18:00:53 <bdpayne> Bryan Payne from Nebula here
18:00:57 <bdpayne> who else do we have?
18:01:04 <noslzzp> Greetings..  Basil from Red Hat.
18:01:27 <malini1> Basil -- hope you did get some sleep!
18:01:46 <noslzzp> A bit!
18:01:51 <bdpayne> ha, nice
18:01:57 <bdpayne> ok, we'll get started
18:02:02 <bdpayne> I'm sure more will join as we go
18:02:10 <bdpayne> #topic Doc Sprint
18:02:32 <bdpayne> so we have dates locked in: June 24-28
18:02:41 * annegentle waves
18:02:41 <bdpayne> we have a location locked in (near BWI)
18:02:49 <bdpayne> hi annegentle
18:03:01 <annegentle> psyched for the doc sprint y'all!
18:03:23 <bdpayne> and we have about 12 people committed to participating
18:04:05 <bdpayne> noslzzp I'd like to explore getting a hotel block
18:04:24 <bdpayne> and we have some logistics to work our regarding food and such
18:04:24 <noslzzp> It's complicated. :)
18:04:30 <bdpayne> complicated?
18:05:19 <noslzzp> So, because we have a sponsor from the IC, the address is sensitive.
18:05:38 <bdpayne> heh
18:05:49 <noslzzp> The last meeting we had there, we didn't get final address details until late.
18:05:58 <bdpayne> well, people will need to book a hotel, right?
18:06:11 <noslzzp> I've asked Shawn to join here real quick.
18:06:17 <swells> noslzzp:  i'm here
18:06:19 <bdpayne> and we'd like to be as close to the site as possible… walking distance is ideal
18:07:12 <mtesauro> who is "the IC" - I missed the last meeting
18:07:23 <noslzzp> Ok.. So I've been the facility in mind.  And it's walking distance from 2-3 hotels.
18:07:32 <noslzzp> "IC" = intelligence community.
18:07:59 <noslzzp> The location is very good for us.  Good wifi, large room, quiet and decent restaurants.
18:08:10 <bdpayne> could we still get a block at one of those hotels and not disclose the actual meeting location until last minute?
18:08:46 <noslzzp> Give me 48 hours to get confirmation from our sponsor.  I'd like to keep protocol in place.
18:09:04 <bdpayne> fair enough
18:09:15 <bdpayne> we can discuss offline once you know more noslzzp
18:09:23 <noslzzp> Shawn is helping with the coordination.
18:09:45 <bdpayne> #action noslzzp / swells to confirm our ability to setup hotel block
18:09:57 <noslzzp> bdpayne, yes, offline as soon as we're fully cleared to share the address.
18:10:11 <noslzzp> Sorry this is so complicated. :)
18:10:24 <bdpayne> no problem
18:10:36 <bdpayne> I used to live in that world, I understand at a deeper level than I care to admit
18:10:46 <noslzzp> heh
18:11:19 <bdpayne> ok, so bottom line here is that logistics are starting to come together
18:11:29 <bdpayne> and we have a great team put together to do the guide
18:11:43 <bdpayne> any other things to discuss regarding the doc sprint?
18:12:20 <bdpayne> ok, we can move forward then
18:12:28 <bdpayne> #topic Ongoing Security Projects
18:12:47 <bdpayne> Anyone here that can provide an update on RPC security, key manager, and/or volume encryption work?
18:13:20 <joel-coffman> I can speak to the volume encryption work
18:13:30 <malini1> Key manager: malini
18:13:45 <bdpayne> joel-coffman let's start with you then
18:14:03 <joel-coffman> We expect to (re)submit our code in another couple of weeks
18:14:04 <mtesauro> I know key manager is actively being developed - I'm on the github and see the commit/pull requests/etc.
18:14:26 <joel-coffman> We're working to incorporate changes requested at the summit
18:15:00 <bdpayne> joel-coffman what can we expect from a functionality perspective from this new code submition?
18:15:44 <joel-coffman> The encryption part should be fully-functional
18:16:09 <bdpayne> without integration into a key manager?
18:16:13 <bdpayne> or with?
18:16:14 <joel-coffman> until the key manager is ready, I don't know how useful it will be in a deployed environment
18:16:27 <bdpayne> right, ok
18:16:54 <malini1> Key manager goal is to have enough in git by May 31 for joel-coffman to get a key and use
18:16:59 <joel-coffman> we aren't quite ready to integrate with the key manager yet
18:17:10 <joel-coffman> that timeline sounds about perfect
18:17:15 <malini1> key manger will support "put" secret, "get" secret
18:17:37 <bdpayne> joel-coffman if you put "SecurityImpact" in your git commit message for the PR, then it will automatically email the security list for review when your code goes up
18:17:50 <malini1> May 31 is Havana-1 deadline, and July 18 havana-2, meeting 1&2 ensures incubation success
18:18:04 <joel-coffman> okay
18:18:32 <bdpayne> sounds good, let us know if there's anything else the security group can do to help there
18:18:42 <bdpayne> malini1 any other details on the key manager work?
18:18:59 <malini1> I am working on keystone integration for key manager
18:19:11 <malini1> and it is coming along
18:19:48 <malini1> jarret from rackspace is working on a client, so slowly all the pieces are coming togeher
18:19:49 <bdpayne> is the architecture / design of the key manager with regards to keystone available anyware?
18:20:18 <malini1> yes, https://github.com/cloudkeep/barbican/wiki/_pages
18:20:36 <mtesauro> Malini - when you say client - do you mean the JS client?
18:21:01 <mtesauro> aka Palisade?
18:21:02 <malini1> the only piece I am not too thrilled is that the rackspace design has a notion of "order", which is asynch to create a key
18:21:32 <malini1> that fits in better for pki private/public and certificate, for a simple asymmetric key that feels like too much overhead
18:21:38 <mtesauro> I suspect that if for SSL cert mgmt.  That process has to be async if dealing with a third party CA
18:22:02 <malini1> the alternative is for the service wanting a secret key to just create it and "put" it into keymanager
18:22:40 <bdpayne> perhaps async is a reasonable first step?  with an optimization available for symmetric keys down the road?
18:22:43 <malini1> exactly, it is for ssl-cert management, but users such as cinder, swift etc are seeking symmetric keys
18:23:04 <malini1> yes, would like support for pitching a fast-pass for symmetric keys
18:23:26 <bdpayne> so is the key store creating the keys.. or just storing them?
18:23:40 <malini1> having a fast-pass for symmetric would better support a use model where there is say and HSM to back the key manager
18:23:53 <malini1> both models support, creating and storing
18:23:59 <bdpayne> ok
18:24:12 <malini1> because storing is supported, do not need to use the asynch path for symmetric keys
18:24:23 <mtesauro> I am a short walk away from Jarret - I can talk to him about this.
18:24:26 <bdpayne> personally, I like creating b/c I suspect that many users will make mistakes in trying to create keys
18:24:39 <bdpayne> mtesauro that would be great
18:25:35 <bdpayne> #action joel-coffman to aim for Havana-1 deadline for submission of volume encryption code
18:25:51 <joel-coffman> will do
18:26:03 <bdpayne> #action mtesauro to discuss symmetric keys use case with Jarret, sync back with malini1
18:26:16 <bdpayne> anything else to discuss?
18:26:58 <bdpayne> ok then… thanks everyone for attending
18:27:03 <bdpayne> I believe we are done for today
18:27:13 <malini1> the point of creation needs to have a good supply of entropy for random numbers, so if the keymanager client has an api call for create key, that would work, most service endpoints for key creation will be on host machines
18:27:31 <malini1> with the necessary entropy
18:28:07 <malini1> thanks everyone
18:28:16 <bdpayne> exactly… and then the key manager could get the entropy correctly
18:28:24 <bdpayne> whereas the clients may not use a proper rng
18:28:29 <bdpayne> which is a pretty common mistake
18:29:11 <bdpayne> #endmeeting