Thursday, 2015-01-08

*** chlong has quit IRC00:01
*** chlong has joined #openstack-barbican00:02
*** jaosorior has quit IRC00:03
*** chlong has quit IRC00:06
*** lisaclark1 has quit IRC00:14
*** lisaclark1 has joined #openstack-barbican00:14
*** lisaclark1 has quit IRC00:19
*** chlong has joined #openstack-barbican00:29
*** kgriffs is now known as kgriffs|afk00:31
*** dougwig is now known as dougwig_the_rude00:41
*** dougwig_the_rude is now known as dougwig00:42
*** arunkant has quit IRC00:53
*** kebray has quit IRC01:17
*** gyee has quit IRC01:36
*** SheenaG1 has joined #openstack-barbican01:48
*** SheenaG11 has joined #openstack-barbican01:50
*** SheenaG1 has quit IRC01:52
*** lisaclark1 has joined #openstack-barbican02:05
*** ryanpetrello has quit IRC02:08
*** chlong has quit IRC02:11
*** SheenaG11 has quit IRC02:20
*** SheenaG1 has joined #openstack-barbican02:28
*** SheenaG1 has quit IRC02:38
*** ryanpetrello has joined #openstack-barbican02:53
*** kebray has joined #openstack-barbican03:18
*** kebray has quit IRC03:19
*** kebray has joined #openstack-barbican03:20
*** zz_dimtruck is now known as dimtruck03:25
*** kebray has quit IRC03:35
*** ryanpetrello has quit IRC03:49
*** chlong has joined #openstack-barbican03:57
*** kebray has joined #openstack-barbican03:59
*** chlong has quit IRC04:02
*** kebray has quit IRC04:17
*** chlong has joined #openstack-barbican04:18
*** dimtruck is now known as zz_dimtruck04:41
*** david-lyle has quit IRC04:50
*** kebray has joined #openstack-barbican05:00
*** lisaclark1 has quit IRC05:20
*** kebray has quit IRC06:21
*** jamielennox is now known as jamielennox|away06:33
*** woodster_ has quit IRC07:10
*** chlong has quit IRC07:47
*** crc32 has quit IRC08:23
*** hyakuhei has joined #openstack-barbican09:22
*** hyakuhei has quit IRC09:42
openstackgerritMerged openstack/barbican: Replace and remove native asserts
*** hyakuhei has joined #openstack-barbican10:04
*** hyakuhei has quit IRC10:06
*** chlong has joined #openstack-barbican11:43
*** hyakuhei has joined #openstack-barbican12:03
*** woodster_ has joined #openstack-barbican12:29
*** ryanpetrello has joined #openstack-barbican12:54
*** hyakuhei has quit IRC12:59
*** hyakuhei has joined #openstack-barbican13:15
*** darrenmoffat has quit IRC13:16
*** ryanpetrello has quit IRC13:16
*** darrenmoffat has joined #openstack-barbican13:17
*** ryanpetrello has joined #openstack-barbican13:17
*** alee has quit IRC13:33
*** hyakuhei has quit IRC13:43
*** ryanpetrello has quit IRC13:50
*** hyakuhei has joined #openstack-barbican14:14
*** hyakuhei has quit IRC14:15
*** nkinder has quit IRC14:16
*** hyakuhei has joined #openstack-barbican14:21
*** kgriffs|afk is now known as kgriffs14:30
*** miqui_ has joined #openstack-barbican14:41
*** alee has joined #openstack-barbican14:49
*** kgriffs is now known as kgriffs|afk14:58
*** lisaclark1 has joined #openstack-barbican15:03
*** nkinder has joined #openstack-barbican15:04
*** ryanpetrello has joined #openstack-barbican15:11
*** kgriffs|afk is now known as kgriffs15:39
*** kebray has joined #openstack-barbican15:51
*** lisaclark1 has quit IRC15:53
*** SheenaG1 has joined #openstack-barbican15:56
*** kebray_ has joined #openstack-barbican16:04
*** kebray has quit IRC16:05
*** hyakuhei has left #openstack-barbican16:09
*** lisaclark1 has joined #openstack-barbican16:15
*** lisaclark1 has quit IRC16:24
*** lisaclark1 has joined #openstack-barbican16:24
*** nkinder has quit IRC16:24
rm_workWoo, I'm back! :)16:26
rm_workSo, any updates on Castellan? I left for three weeks right after signing up to do a spec BP for the Certificate Management interface… <_<16:27
SheenaG1rm_work: who is this?  I don't remember you.16:28
jvrbanacrm_work, not yet. CR's accepted!16:29
SheenaG1rm_work: I think I need a cake to remember you better...16:29
chellygelCastellan is such a great name16:29
rm_workyes :)16:29
rm_workjvrbanac: CR for adding the Castellan repo?16:30
rm_workor for something further?16:30
jvrbanacrm_work, it was merged.
*** chlong has quit IRC16:34
rm_workSo I guess I'll wait for whoever is doing the primary interface spec, comment on that if I see any problems down the road, then write the cert spec to be complimentary16:34
rm_workWho was going to be writing that spec? Did someone sign up for it?16:34
jvrbanacrm_work, I'm not sure at the moment.16:35
rm_workok. do we have a target timeline?16:35
rm_workI am guessing not Kilo?16:36
jvrbanacredrobot, ^^16:36
rm_workis redrobot back? :P16:36
*** nkinder has joined #openstack-barbican16:38
*** gyee has joined #openstack-barbican16:39
jvrbanacrm_work, he is, but I think he's running a couple errands this morning. He should be around a little later16:39
rm_workcool, k16:39
SheenaG1rm_work: thanks for acknowledging my trolling.  I can go back to work now.16:43
chellygelsomething something that cake is a lie something16:44
openstackgerritJohn Vrbanac proposed openstack/barbican: Moving exception logging in the base behaviors
jvrbanacalee, redrobot, reaperhulk, rellerreller, hockeynut, could we get a workflow on: ?16:51
redrobotjvrbanac I'll take a look at it16:54
jvrbanacredrobot, thx16:54
redrobotrm_work happy 2015!  ...  last I heard one of the JHU folks was going to be working on fleshing out the Castellan interface, and also sending patches to Cinder, Glance, etc.16:55
rm_workerr, JHU?16:56
redrobotrm_work is live already16:56
redrobotrm_work John's Hopkins University16:56
rm_workah k. yeah, i saw that :P unfortunately not much there yet16:56
redrobotrm_work I'll add an agenda item to ask rellerreller about it next Monday16:57
*** kebray_ has quit IRC16:58
*** vb has joined #openstack-barbican16:58
aleejvrbanac, made comment on cr16:58
*** vb has left #openstack-barbican16:59
rm_workredrobot: I assume that Kilo is unrealistic as a possible timeframe though, right? so I'll have to continue with my temporary work directly in neutron-lbaas so we have something until Castellan is ready?16:59
rm_workie, if we need an interface by Kilo, I shouldn't hold out for Castellan16:59
redrobotrm_work we still have a couple of months before feature freeze... I don't think the interface will be that much work...   maybe it's something we can work on during the mid-cycle meetup.17:01
rm_workwhere did that end up being?17:01
*** tkelsey has joined #openstack-barbican17:01
redrobotrm_work Austin17:02
rm_workthat isn't too bad17:02
*** SheenaG1 has quit IRC17:03
*** bdpayne has joined #openstack-barbican17:04
rm_workah, found it too17:04
*** ChanServ sets mode: +o redrobot17:04
rm_worki can hopefully make that'17:04
rm_worktrying to remember when the neutron-lbaas one is17:05
*** lisaclark1 has quit IRC17:05
*** redrobot changes topic to "Barbican Kilo Mid-Cycle Sprint Feb. 16-18, Austin, TX."17:05
*** kebray has joined #openstack-barbican17:06
redrobotjvrbanac should that exception be re-raised to bail out?  As written it will return None (I think) and blow up elsewhere...17:07
*** lisaclark1 has joined #openstack-barbican17:07
jvrbanacredrobot, no. We don't want to re raise. See line 2917:08
jvrbanacdefaults to a dict17:08
jvrbanacIt'll just return an empty dict17:08
redrobotjvrbanac heh.. totally missed that.  I think alee did too. :)   Ok, sounds good to me.  WORFLOWEDED17:09
jvrbanacThis will allow the tests to assert correctly instead of bailing17:09
*** lisaclark1 has quit IRC17:09
*** lisaclark1 has joined #openstack-barbican17:11
aleejvrbanac, if the tests assert correctly without bailing, how will we know that there are issues?17:13
aleeredrobot, ^^17:13
aleejvrbanac, I appreciate that this intermittent error is holding things up -- it affected me the other day too - but shouldn17:14
aleeshouldn't we be trying to figure whats causing this issue?17:15
aleeif you do this - any future issues will be masked.17:15
alee(after all - no one checks the logs if the tests passed)17:16
redrobotalee I presume that the empty dict would make the tests fail anyway, but you do make a good point.17:17
*** paul_glass has joined #openstack-barbican17:21
*** paul_glass has quit IRC17:23
*** SheenaG1 has joined #openstack-barbican17:25
openstackgerritMerged openstack/barbican: Adding error handling to help debug devstack issue
*** kebray has quit IRC17:34
aleebdpayne, ping17:58
aleebdpayne, were you the one advocating for the  cert api generated from an existing stored private/public key pair?17:59
bdpayneroughly, yeah17:59
aleebdpayne, I thought so .. just to be clear, its the "stored-key" option in,cm18:00
aleeoption 3 ..18:00
* bdpayne looks18:00
aleebdpayne, if it is, I'd like to understand the use case for this -- because implementing this is problematic18:01
bdpayneso that is about what I was thinking18:02
bdpaynebut there may be other ways to accomplish this too18:02
bdpaynethe idea being that you could ask barbican for a new cert18:02
bdpaynethe priv key could be stored in barbican already18:03
bdpayneso barbican could just update that certs expiration date18:03
bdpaynethis could be useful for an ephemeral pki18:03
bdpaynealthough there is now a new emphemeral pki project proposed by hp18:03
bdpayneand I haven't had a chance to explore that too much yet18:03
bdpayneit may fill in some of these gaps18:03
bdpaynewhy is this hard to implement?18:04
aleebdpayne, I see - so this is a renewal thing ..18:04
bdpaynelargely, but could be used for intial generation too18:04
bdpayneseems like, either way, a client could do this via multiple operations18:05
aleeits hard because in order to generate a csr, barbican core would need to retrieve the private key to sign the csr.18:05
bdpaynebut the plus would be to keep the private key inside barbican rather than needing to pull it out to build a csr18:05
aleewhich means that the private key would be in memory in barbican18:05
bdpaynesure, but it would be doing that for a user anyway, right?18:05
bdpaynewouldn't that need to happen if I, as a user, requested that priv key anyway?18:06
aleenot necessarily -- not if there were some transport key wrapping18:06
aleeor we did something like encrypt the key with a passphrase18:07
bdpayneI see18:07
bdpaynebut then you are just pushing the problem onto the user, right?18:07
bdpayneuser gets priv key18:07
*** gyee has quit IRC18:08
bdpayneuser decrypts it18:08
bdpayneuser then has to deal with it being in memory, etc18:08
aleebdpayne, yes -- well it is his private key ..18:08
aleebdpayne, the normal way of doing things is to have the user generate a public/private key pair18:08
bdpayneso is the expectation with barbican that the secrets are typically encrypted by the user before storage in barbican?18:09
bdpaynefor me, that somehow seems to defeat the purpose, but perhaps I'm missing something18:09
aleenot necessarily no18:09
aleebut if I were security paranoid, I would want to interact with barbican in a way that was guarenteed to be secure18:10
bdpayneso it sounds like the best path here is just to have an external service that manages the key creation and the csr generation18:10
bdpayneso the difference is saying that you expect each user to secure their stuff, versus asking barbican to do it correctly once18:11
bdpaynebut I can solve that by putting some middle ware in between barbican and user18:11
bdpayneso I'm ok with that18:11
aleebdpayne, well - right now, we have the ability to generate a pub/priv key in barbican18:12
bdpayneand this is what prompted me to think of this use case18:12
aleebdpayne, and I suppose we could do the stored-key thing by asking the plugins to sign the csr18:13
alee(without extracting the private key)18:13
aleebdpayne, I was just trying to understand the use case -- how can the client use the cert without the private key?18:14
bdpaynecertainly the priv key will be needed at some point18:14
bdpaynejust trying to limit the back and forth18:14
bdpaynebut, like I said, this can be solved in middleware too if it doesn't make sense to do it in barbican18:15
aleebdpayne, it can be solved in barbican if we do what I suggest above .. but if the client will need the private key in any case ..18:16
bdpayneanother way to view this... the code that needs to use the priv key in operation is likely different than the code that needs to renew the cert18:16
bdpayneso I think we're talking about different clients18:16
dstufftit certainly seems counterproductive to be designing barbican use cases around the idea that people don't trust barbican to store their secrets18:16
bdpayneperhaps I have one client that needs the priv key to renew the cert18:16
bdpayneand another than needs it for running some service18:16
bdpayneI'd rather just have the one that runs the service and have that cert renewal not need to involve yet another piece of code18:17
bdpaynedstufft yeah (and hi!)18:17
*** zz_dimtruck is now known as dimtruck18:18
dstufftbdpayne: heya :D18:18
dstufftif I don't trust barbican to store a secret then it feels like I'm not much better off than just using a regular dumb oject store18:18
aleedstufft, think of it this way.  Part of the reason we want people to use barbican is we expect barbican to be a place where we do secrets and encryption right.18:18
dstufftalee: sure, so why would we expect people to encrypt things before they give them to us?18:19
aleewe don't expect barbican to be hacked -- but if it was - we'd expect that it would be doing things in such a way as to not expose secrets if it were.18:19
aleeand one way of doing that is not exposing secrets unencrypted in memory18:20
dstufftI mean, I'm sure someone out there will encrypt things before sending them to barbican because people do things that I don't completely understand ;) but it feels like that's going to be a fairly edge case18:20
aleedstufft, well .. once I add transport key wrapping to the barbican client, it will be possible to encrypt all secrets by default through barbican18:21
alee(if someone  chooses to)18:21
dstufftalee: won't they then have to manage the secret that decrypts the secrets stored in barbican?18:22
aleedstufft, there is a difference between transport key wrapping and secret pre-encryption18:23
bdpaynebut this key wrapping will require a client-side secret, right?18:23
aleetransport key wrapping means wrapping the secret with a plugin-side secret18:24
aleeso it goes through barbican wrapped to the plugin18:24
bdpayneso the plugin knows the secret, and so does the client?18:25
aleesecret pre-encryption means using a client-side secret to pre-encrypt the secret18:25
dstufftalee: I'm not sure I grok what the transport key wrapping thing is, but It seems counterproductive. If the clients are participating in it and they need to have a secret, then it seems like that's just adding back in the thing that barbican is supposed to be managing for people, if it's only happening internal to barbican itself then it seems likt it's not actually doing anything18:27
bdpayneso transport key wrapping is like setting up a TLS tunnel between the client and the plugin?18:27
aleebdpayne, dstufft  -- ok -- so let me describe transport key wrapping  ..18:28
aleeat least how it is done in dogtag ..18:29
aleedogtag drm has a public/private key pair for secret transport18:29
aleeit provides the public key to barbican18:30
aleethe client gets this public key - and uses it to wrap the secret for storage18:30
*** lisaclark1 has quit IRC18:30
aleethen - only the drm (the backend where the secret is to be stored) can decrypt the secret and store it.18:30
dstuffthow does the client get the secret back out18:31
aleebarbican-core never has the secret exposed.18:31
aleeok ..18:31
aleeso barbican client generates a session key and wraps it with the transport public key18:31
aleesend that to barbican core - which sends that to the plugin18:32
aleeplugin decrypts the session key and wraps the secret with it18:32
dstufftso what stops someone who has hacked barbican core from generating the session key and wrapping it with the transport public key18:32
*** lisaclark1 has joined #openstack-barbican18:32
aleeonly the client can decrypt the secret -- no one else can decrypt it in between18:32
*** tkelsey has quit IRC18:32
bdpayneso, ignoring my feelings on this scheme for a moment, I imaging that the plugin (dogtag in this case) could generate the CSR18:33
bdpayneand that would remove all concerns of barbican-core having the priv key18:34
aleedstufft, well, thats a completely different attack vector -- I'd think you'd be well and truly screwed if someone could do that18:34
aleebdpayne, yes18:34
aleebdpayne, and thats one approach too.18:34
aleebdpayne, or barbican core can create the csr and the plugin could sign it18:35
dstufftalee: so the attack vector you're worried about is someone who can read arbitrary memory but can't send messages to the dogtag instance pretending to be barbican-core?18:35
aleedstufft, yup18:35
bdpaynebasically, they can read, but not write memory18:35
bdpaynein my world, if someone could do that, then they could probably do these other things too18:36
dstufftthat doesn't sound like a very plasuable attack scenario to me?18:36
bdpayneat least we're all on the same page now18:36
dstufftlike it seems like a lot of extra complexity for not a whole lot of benefit18:37
bdpayneI do need to go afk for a few, but have I answered your questions alee?18:37
aleeI think so -- like I said - we can do the stored-key thing, -- I was just trying to understand what the use case was18:37
bdpayneok, cool18:38
aleeie. why the client could not generate the csr.18:38
* bdpayne --> afk18:38
*** bdpayne has quit IRC18:38
*** lisaclark1 has quit IRC18:39
aleedstufft, not sure I agree with that -- but in any case, not having unencrypted secrets outside of say - an HSM - is something that is required for things like common criteria certification.18:41
openstackgerritOpenStack Proposal Bot proposed openstack/barbican: Updated from global requirements
dstufftalee: well, don't the clients have the secrets unencrypted when they want to use them?18:42
aleedstufft, yes -- but its the clients secret - they are responsible for their own security18:43
dstufftalee: but what i'm saying is, is there any way to actually use a secret that's stored in barbican without having it unecnrypted otuside of an HSM? If they are uncrypted on the client side surely that fails common criteria certification right there?18:44
aleedstufft, think of it as separate security concerns -- there is the security of the storage system -- and the security of the client18:45
aleewe're concerned with the former, not the latter18:46
dstufftalee: except it's also the security of the storage system because barbican-core can ask dogtag to decrypt any secret at any time18:46
dstufftI guess I'm just having a hard time imagining a scenario where someone can read arbitrary memory but can't also write arbitrary memory18:49
*** bdpayne has joined #openstack-barbican18:53
aleeyeah - maybe I'm being over-paranoid ..18:54
*** jorge_munoz has quit IRC18:55
aleedstufft, I can put in a switch -- if someone is worried about CC certifcation - they can always disable this mechanism18:56
dstufftalee: IRC may or may not be a good means for fully descibing the scenario too, and I certainly don't want to say that I'm fully groking what you're getting at with it after thinking about it for 45 minutes. So my thoughts are very much off the cuff with the little bit i know about it. I also don't know much about dogtag in general. Is there a blueprint for this at all?18:58
aleedstufft,  the transport key stuff ?  thats already in the code base -- at least on the server side18:59
alee(as part of juno)19:00
dstufftah, I must have missed it then19:02
* dstufft goes to dig up the code19:02
aleedstufft,  think about it this way too.  Why would I want to use an HSM ?  Because I'm security paranoid and I don19:02
aleeI don't want my private stuff to be exposed in the clear.  Thats what an HSM will guarantee.  that my secret will never leave the HSM in the clear.19:03
aleenow we're talking about writing code in barbican-core that requires manipulating secrets in the clear19:04
dstufftalee: well, except as long as the client can get the secret out there's no guarentee that the secret will never leave the HSM in the clear19:04
dstufftafaik barbican cannot operate as a HSM, (e.g. I can't get OpenSSL on a client to offload cryptographic operations to it), so comparing it to an HSM doesn't seem super useful19:06
dstufftfundamentally barbican has to have the ability to get the secret in the clear unless you store a secret on the client side, generating a session key on the client side doesn't prevent that because barbican itself can just generate a session key19:07
*** jorge_munoz has joined #openstack-barbican19:08
*** kebray has joined #openstack-barbican19:09
*** jorge_munoz has quit IRC19:09
aleeok  .. fair enough .. fwiw, transport key wrapping is also there to protect in case ssl from barbican client to barbican is compromised19:10
aleebecause sometimes people do dumb things .. like terminate ssl connections before they get to barbican19:11
aleebut thats another issue ..19:11
dstufftyea :(19:12
alee(or use bad ciphers etc.)19:12
dstufftif people configuring TLS wrong is in scope for things barbican should protect against we'd probably be better off implementing something generic (e.g. not specific to dogtag) that operates on things as part of the ingress/egress insdie of barbican-core before they pass to the plugins themselves. Namely because if that's something we want to protect against we probably want to protect against it in situations where people aren't19:14
dstufft using dogtag as well19:14
dstufft(although I recognize that the scheme would certainly protect against that if someone is using dogtag in that way)19:15
aleedstufft, well the scheme is pretty generic -- its just based on public/private key and an asn.1 structure19:16
aleedstufft, anyways - one thing I was going to think about is adding transport key support to the default barbican plugins -- but thats L at least19:18
*** paul_glass has joined #openstack-barbican19:20
dstufftalee: I'm not saying the scheme itself couldn't be adapted elsewhere, just that as I understand it, it currently relies on using dogtag in a specific configuration for it to be used, and if it's something that barbican should seriously be protecting against then we probably should do it a layer above the plugins (although I don't personally really think "I didn't deploy barbican sanely" is something that's worth adding extra19:20
dstufft mechanisms for)19:20
*** kgriffs is now known as kgriffs|afk19:22
aleegotta get lunch ..19:23
*** alee is now known as alee_late_lunch19:23
*** paul_glass1 has joined #openstack-barbican19:24
*** paul_glass has quit IRC19:27
*** atiwari has joined #openstack-barbican19:28
*** atiwari1 has joined #openstack-barbican19:29
*** bdpayne has quit IRC19:45
*** bdpayne has joined #openstack-barbican19:46
*** lisaclark1 has joined #openstack-barbican19:47
*** lisaclark1 has joined #openstack-barbican19:47
*** paul_glass1 has quit IRC19:48
*** kgriffs|afk is now known as kgriffs19:48
*** atiwari1 has quit IRC19:51
*** atiwari has quit IRC19:51
*** atiwari has joined #openstack-barbican19:52
*** atiwari1 has joined #openstack-barbican19:52
*** atiwari1 has quit IRC19:54
*** atiwari has quit IRC19:54
*** atiwari has joined #openstack-barbican19:54
*** atiwari has quit IRC19:54
*** atiwari has joined #openstack-barbican19:55
*** kgriffs is now known as kgriffs|afk20:03
*** kgriffs|afk is now known as kgriffs20:09
*** atiwari has quit IRC20:13
*** paul_glass has joined #openstack-barbican20:17
*** paul_glass has quit IRC20:22
*** alee_late_lunch is now known as alee20:24
*** jorge_munoz has joined #openstack-barbican20:29
*** jorge_munoz has joined #openstack-barbican20:35
*** jorge_munoz has quit IRC20:44
*** lisaclark1 has quit IRC20:53
*** david-lyle has joined #openstack-barbican20:54
*** csoukup has joined #openstack-barbican20:55
*** bdpayne has quit IRC20:57
*** bdpayne has joined #openstack-barbican20:58
*** paul_glass has joined #openstack-barbican21:12
*** paul_glass has quit IRC21:16
*** jamielennox|away is now known as jamielennox21:24
*** lisaclark1 has joined #openstack-barbican21:29
*** jorge_munoz has joined #openstack-barbican21:34
*** lisaclark1 has quit IRC21:34
*** nkinder has quit IRC21:43
*** ryanpetrello has quit IRC21:53
*** bdpayne has quit IRC21:55
*** crc32 has joined #openstack-barbican22:06
openstackgerritMerged openstack/barbican: Moving exception logging in the base behaviors
*** bdpayne has joined #openstack-barbican22:24
*** alee has quit IRC22:24
*** david-lyle has quit IRC22:28
*** SheenaG1 has quit IRC22:29
*** tkelsey has joined #openstack-barbican22:31
*** tkelsey has quit IRC22:35
*** nkinder has joined #openstack-barbican22:37
*** crc32 has quit IRC23:06
*** csoukup has quit IRC23:12
*** kgriffs is now known as kgriffs|afk23:33
*** kgriffs|afk is now known as kgriffs23:37
*** SheenaG1 has joined #openstack-barbican23:38
*** alee has joined #openstack-barbican23:39

Generated by 2.14.0 by Marius Gedminas - find it at!