Monday, 2014-10-20

*** woodster_ has quit IRC00:30
*** woodster_ has joined #openstack-barbican01:38
*** zz_dimtruck is now known as dimtruck01:43
*** dimtruck is now known as zz_dimtruck01:43
*** zz_dimtruck is now known as dimtruck01:45
*** dimtruck is now known as zz_dimtruck02:01
*** alee has quit IRC02:13
*** alee has joined #openstack-barbican02:28
*** bubbva has quit IRC03:30
*** bubbva has joined #openstack-barbican03:31
*** ryanpetrello has quit IRC03:40
*** ryanpetrello has joined #openstack-barbican03:41
*** ayoung is now known as ayoung-ZZZzzz03:57
*** kebray has joined #openstack-barbican05:02
*** kebray has quit IRC05:03
*** kebray has joined #openstack-barbican05:04
*** rm_you| has joined #openstack-barbican05:07
*** rm_you has quit IRC05:09
*** woodster_ has quit IRC06:40
*** alee has quit IRC07:04
*** jamielennox has joined #openstack-barbican07:50
*** davidhadas_ has joined #openstack-barbican12:09
*** woodster_ has joined #openstack-barbican12:41
*** alee has joined #openstack-barbican12:49
*** ametts has joined #openstack-barbican13:32
*** lisaclark1 has joined #openstack-barbican13:52
*** ametts has quit IRC14:06
*** SheenaG1 has joined #openstack-barbican14:09
*** ametts has joined #openstack-barbican14:16
*** tdink has joined #openstack-barbican14:17
*** ayoung-ZZZzzz is now known as ayoung14:17
*** nkinder has joined #openstack-barbican14:20
*** lisaclark1 has quit IRC14:38
*** paul_glass has joined #openstack-barbican14:43
*** lisaclark1 has joined #openstack-barbican14:43
*** paul_glass1 has joined #openstack-barbican14:43
*** jorge_munoz has joined #openstack-barbican14:47
*** paul_glass has quit IRC14:47
*** lisaclark1 has quit IRC14:49
*** jorge_munoz has quit IRC14:52
*** jorge_munoz has joined #openstack-barbican14:52
*** zz_dimtruck is now known as dimtruck14:53
*** davidhadas_ has quit IRC14:55
*** kgriffs|afk is now known as kgriffs15:03
*** lisaclark1 has joined #openstack-barbican15:13
*** lisaclark2 has joined #openstack-barbican15:17
*** lisaclark2 has quit IRC15:18
*** lisaclark2 has joined #openstack-barbican15:18
*** lisaclark1 has quit IRC15:20
*** paul_glass1 has quit IRC15:33
*** paul_glass has joined #openstack-barbican15:37
*** gyee has joined #openstack-barbican15:47
*** lisaclark2 has quit IRC16:07
*** lisaclark1 has joined #openstack-barbican16:10
*** ayoung is now known as ayoung-dogwalkin16:18
*** davidhadas has joined #openstack-barbican16:24
*** lisaclark1 has quit IRC16:28
*** lisaclark1 has joined #openstack-barbican16:32
*** jamielennox has quit IRC16:37
*** paul_glass has quit IRC16:42
*** paul_glass has joined #openstack-barbican16:42
*** lisaclark1 has quit IRC16:47
rm_workredrobot: any ideas on timeline for client 3.0?16:48
rm_workwoodster_: ^^ ?16:48
woodster_rm_work, I think redrobot mentioned end of this week...good to bring up during IRC today16:53
*** lisaclark1 has joined #openstack-barbican17:01
*** gyee has quit IRC17:03
*** jaosorior has joined #openstack-barbican17:07
*** davidhadas has quit IRC17:11
*** davidhadas_ has joined #openstack-barbican17:15
*** atiwari has joined #openstack-barbican17:21
*** davidhadas_ is now known as davidhadas17:23
aleeatiwari, ping17:25
*** ayoung-dogwalkin is now known as ayoung17:26
*** bdpayne has joined #openstack-barbican17:26
*** lisaclark1 has quit IRC17:33
atiwarialee yes17:38
aleeatiwari, do you know Stanislaw Pitucha /17:39
alee?17:39
atiwarialee yes17:40
aleeatiwari, I'd like to re-submit his https://review.openstack.org/#/c/108429/  for kilo.17:40
aleeatiwari, or ask him to do it -- its a good start on something we definitely need to do in kilo17:40
atiwariok, let me start17:41
atiwariI will let you know17:41
aleeatiwari, cool thanks17:41
*** rellerreller has joined #openstack-barbican17:41
*** lisaclark1 has joined #openstack-barbican17:41
aleeatiwari, also -- take a look at https://review.openstack.org/#/c/127353/17:41
aleeatiwari, I think this will give you what you want for pre-user secrets17:42
atiwarialee sure, is it regarding the ownership?17:42
atiwarigreat17:42
aleeatiwari, if stanislaw just wants to resubmit and reference back to the previous one so that folks can see the comments, that will be ok too.17:43
atiwariok17:44
aleeatiwari, but hopefully we can get some good discussion started on this prior to the summit17:44
atiwarisure17:44
*** lisaclark1 has quit IRC17:49
*** lisaclark1 has joined #openstack-barbican17:53
*** dimtruck is now known as zz_dimtruck18:13
openstackgerritArvind Tiwari proposed a change to openstack/barbican-specs: Spec for certificate REST api addition  https://review.openstack.org/12969518:13
openstackgerritArvind Tiwari proposed a change to openstack/barbican-specs: Spec for certificate REST api addition  https://review.openstack.org/12969518:17
*** arunkant has joined #openstack-barbican18:20
atiwarialee, fyi I have moved the spec to kilo and I will own it.18:22
aleeatiwari, fantastic -thanks18:23
openstackgerritDouglas Mendizábal proposed a change to openstack/python-barbicanclient: Refactored Client to use Keystone Sessions  https://review.openstack.org/12786218:28
openstackgerritArvind Tiwari proposed a change to openstack/barbican-specs: Spec for certificate REST api addition  https://review.openstack.org/12969518:33
*** lisaclark1 has quit IRC18:41
*** zz_dimtruck is now known as dimtruck18:43
*** lisaclark1 has joined #openstack-barbican18:45
rm_workmeeting is ... 3pm? or is it 2pm?18:52
rm_workredrobot / woodster_ ^^18:52
*** ametts has quit IRC18:52
redrobotrm_work 3pm CDT18:52
rm_workkk18:52
*** tdink_ has joined #openstack-barbican18:55
*** nkinder has quit IRC18:56
*** tdink_ has quit IRC18:57
*** tdink_ has joined #openstack-barbican18:58
*** tdink has quit IRC18:58
*** tdink_ has quit IRC19:03
*** tdink has joined #openstack-barbican19:05
*** tdink has quit IRC19:05
*** kebray has quit IRC19:14
*** dimtruck is now known as zz_dimtruck19:19
*** zz_dimtruck is now known as dimtruck19:23
*** kebray has joined #openstack-barbican19:29
*** dimtruck is now known as zz_dimtruck19:37
*** tdink has joined #openstack-barbican19:45
*** zz_dimtruck is now known as dimtruck19:48
*** kaitlin-farr has joined #openstack-barbican19:50
*** kaitlin-farr has quit IRC19:54
*** kaitlin-farr_ has joined #openstack-barbican19:54
*** nkinder has joined #openstack-barbican19:57
*** kaitlin-farr__ has joined #openstack-barbican19:58
*** kaitlin-farr__ is now known as kaitlin-farr19:58
*** kaitlin-farr_ has quit IRC19:59
*** kaitlin-farr_ has joined #openstack-barbican19:59
*** kaitlin-farr_ has quit IRC19:59
*** kaitlin-farr__ has joined #openstack-barbican20:00
redrobothey it's time for the weekly meeting on #openstack-meeting-alt20:01
*** kaitlin-farr has quit IRC20:03
rm_workgah20:24
rm_workredrobot: just caught up, almost missed it again. this keymanager interface discussion is interesting and promising20:27
*** lisaclark1 has quit IRC20:33
*** lisaclark1 has joined #openstack-barbican20:39
*** gyee has joined #openstack-barbican20:45
*** ametts has joined #openstack-barbican20:52
*** jaosorior has quit IRC20:53
*** hyakuhei has joined #openstack-barbican21:02
*** tkelsey has joined #openstack-barbican21:02
hyakuheiTo continue toe conversation, key-wrapping on HSM is part of the KMIP standard21:03
hyakuhei1.0 and 1.221:03
*** tdink_ has joined #openstack-barbican21:03
aleerellerreller, what I'm confused about -- and I have not looked at the CR really -- is - if the Atalla is so KMIP compliant - why tkelsey and hyakuhei can't use the kmip secret store plugin.21:03
tkelseyalee: because KMIP was not part of Barbican at that point, well not implemented. Also libKMIP was not released when we started the work.21:04
rellerrelleralee We are using the KMIP appliance to store all of the keys in a KMIP server. My guess is they cannot store that many keys. They probably only want to store the KEKs in there.21:04
*** lisaclark1 has quit IRC21:05
hyakuheirellerreller: Yes, we'd only want to store KEK21:05
rellerrellerhyakuhei: So your plan is store KEKs in KMIP. Then on retrieving a key you would retrieve KEK from KMIP, decrypt the wrapped DEK, and return to Barbican core?21:06
*** tdink has quit IRC21:07
*** tdink_ has quit IRC21:07
hyakuheiOur ideal solution would create and store KEK in HSM via KMIP. Wrapping/Unwrapping of DEK done on HSM21:07
tkelseyrellerreller: yes, the key (un)wrapping would be done on the HSM ideally. However the details still need to be worked out :)21:08
atiwarihyakuhei, what is difference between DEK and KEK?21:08
hyakuheiDEK - Data Encryption Key (That which encrypts things in OpenStack)21:08
hyakuheiKEK - Key Encryption Key - used to protect DEKs21:08
atiwarihyakuhei, DEK is the actual secret?21:09
rellerrellerSo you really want an HSM that is also KMIP compliant?21:09
hyakuheirellerreller: Don't we all?21:09
hyakuheiIn fact our HSMs are21:09
rellerrellerhyakuhei haha :) Good point!21:09
hyakuhei_very_ KMIP compliant - however we felt that KMIP support in OpenStack was going to take a while to land / become stable21:10
hyakuheiafter all, the pykmip library was only release a month ago right ?21:10
rellerrellerYa, something like that21:10
hyakuheiSo we went ahead and built something that used the much simpler (if less capable) xml interface that the ESKM exposes with the intention to use that immediately and work to support/stabilse KMIP at which point we'd migrate over21:11
aleetkelsey, hyakuhei and there is some api call in KMIP that allows you to send the encrypted DEK to the HSM , unencrypt with the KEK - and return the unwrapped DEK?21:12
aleejust trying to understand what the end-state would be ..21:12
hyakuheialee: that's my understanding yeah21:13
atiwarihyakuhei, in this pkcs#11 plugin implemented by Paul https://review.openstack.org/#/c/107775/4/specs/juno/restructure-pkcs11-plugin.rst KEKs and DEK are stored locally and propagated to HSM as per need.21:13
tkelseyatiwari: the KEK is sent _to_ the HSM ??21:14
hyakuheiThat's the mode of operation that's just been -1'd for our plugin.21:14
hyakuheitkelsey: atiwari basically that's just using the HSM as a secure file store21:14
hyakuheiA fips-140.3 data store21:14
tkelseyah ok21:14
atiwaritkelsey, hyakuhei that is the pattern to overcome the HSM storage issues.21:15
hyakuheior a fileserver with epoxy resin slathered all over it, to use the full fips definitiion21:15
atiwariIMO21:15
hyakuheiatiwari: no it isn't21:15
tkelseyhyakuhei: lol21:15
hyakuheiHSM handling KEK will scale to several million keys21:15
hyakuheiwhile guarenteeing that even massive compromises of Barbican core will have only limited key impact21:16
hyakuheiand the audit stream of the HSM can reveal exactly what keymat may have been compromised21:16
hyakuheiWhen Barbican core handles KEK and DEK you're basically screwed21:16
tkelseywith the DEK stored locally and wrapped by a KEK the number of keys should be within capacity for a HSM.21:16
tkelseyhyakuhei: +1 for sure21:17
hyakuheiA system with any scale will end up keeping some notional MKEK always in memory21:17
hyakuheiNow what I don't know about KMIP is if it supports the notion of multiple clusters if if that'd be a metadata issue21:17
hyakuheii.e if there are smaller HSMs, lets say they support only a few hundred keys21:18
hyakuheithen in that case you'd need a smart way to scale. My preferred way to do that would be to buy more ESKM21:18
hyakuheis/ESKM/HSM21:18
hyakuheiSo if you have multiple HSM how does Barbican know which one to retrieve keymaterial from?21:18
hyakuheiProbably need to store something with the KEK(DEK) that tells Barbican where the KEK is stored21:19
tkelseyhyakuhei: interesting, guess you would need somthing in the metadata for that21:19
hyakuheiyeh21:19
rellerrellerI agree21:20
-openstackstatus- NOTICE: Zuul erroneously marked some changes as having merge conflicts. Those changes have been added to the check queue to be rechecked and will be automatically updated when complete.21:20
*** lisaclark1 has joined #openstack-barbican21:21
hyakuheiIs that something we want to add sooner rather than later? KMIP endpoint or something similar? I'm unfamiliar with HSM clustering and KMIP21:22
aleehyakuhei, tkelsey - you might want to see if the atalla supports pkcs11 -- this problem of encrypting/decrypting on the hsm has been solved there.21:23
hyakuheialee: It may do, but my feeling is that KMIP support is where interopability with HSMs is going21:24
hyakuheiWell, mine and the rest of the crypto industry ;)21:24
hyakuheiYou'll see less pkcs11 in the future I'd imagine, so if anything I think we should be looking to help develop KMIP21:25
hyakuheierm21:25
hyakuheiDevelop pykmip21:25
tkelseyhyakuhei: +121:25
hyakuheiThe standard supports keywrapping and the devices do21:25
hyakuheiI think the library needs work to support it21:25
hyakuheiand then the plugin for Barbican needs developing21:25
hyakuheiwhich brings us back around to our interim ESKM plugin21:26
rellerrellerhyakuhei +1 for develop pykmip!21:26
tkelseyyeah, KMIP is future looking, the plugin works with whats available right now21:26
aleehyakuhei, fair enough - but it depends on your time scale.  You may be able to put together a more secure solution using pkcs11 before the kmip library is where you need it to be.21:26
aleehyakuhei, tkelsey - if your customers will be happy with the interim plugin , then ok ..21:27
hyakuheialee potentially yes, difference between offloaded .vs. local wrapping is that local is succiptible to comrpomise through info leakage21:28
aleebut most folks who care about this may not look at having the kek in memory favorably21:28
hyakuheiIt's not the best way to do things, I think we're all agreed on that21:28
hyakuheiHowever, it's significantly better than doing _everything_ locally21:29
aleeI know it would be a non-starter for most of our customers.21:29
hyakuheiWell, Barbican as a whole would be in it's current tate21:29
hyakuhei*state21:29
hyakuheiIt's all about moving things forward21:30
aleeyup21:30
tkelseyhyakuhei alee +1 moving forward21:30
tkelseythis is a very interesting discussion but I have to log here, very good points from all though!21:31
hyakuhei+1, late o'clock in the UK21:31
hyakuheiThanks for the discussion alee, rellerreller21:31
tkelseyhyakuhei: heh yeah. yeah rellerreller alee good input!21:31
woodster_lots of discussion here I'm catching up on, but regarding the current pkcs11 plugin that reaperhulk developed (here: https://github.com/openstack/barbican/blob/master/barbican/plugin/crypto/p11_crypto.py) it works with a single MEK stored in the HSM, to wrap per-project KEKs. Only the MEK is stored in the HSM, with per-project KEKs wrapped by the MEK stored21:36
woodster_in barbican. All encrypt decrypt operations happen on the HSM. He HMACs the wrapped KEKs for further integrity.21:36
woodster_so it sounds like KMIP would support similar functionality?21:37
hyakuheiThanks woodster_ I'll take a closer look at that21:37
hyakuheifundamentally I think we need to add wrapping support to the KMIP libraries and then use that in a Barbican plugin21:37
hyakuheiThe real discussion is around what happens in the meantime21:38
hyakuheiAnyway I gotta drop, I'll try to come back to discuss more in the next day or two.21:38
*** tkelsey has quit IRC21:38
woodster_hyakuhei, so it looks like that code is handling the encrypt/decrypt itself, but it's really working with either handles to the HSM-internal KEKs, or else 'extracted' but HSM-encrypted KEKs. So either way, only the HSM itself ever sees unencrypted KEKs21:39
woodster_tkelsey: ^^^^21:39
hyakuheiThanks woodster_ :)21:40
*** openstackgerrit has quit IRC21:40
woodster_hyakuhei, good discussions!21:41
*** ametts has quit IRC21:41
*** tdink has joined #openstack-barbican21:51
*** paul_glass has quit IRC21:54
*** lisaclark1 has quit IRC22:01
*** rellerreller has quit IRC22:08
*** SheenaG11 has joined #openstack-barbican22:12
*** kaitlin-farr__ has quit IRC22:13
*** SheenaG1 has quit IRC22:14
*** dimtruck is now known as zz_dimtruck22:18
*** zz_dimtruck is now known as dimtruck22:20
*** openstackgerrit has joined #openstack-barbican22:43
*** atiwari has quit IRC23:02
*** dimtruck is now known as zz_dimtruck23:16
*** kgriffs is now known as kgriffs|afk23:31
*** rm_you| has quit IRC23:43
*** gyee has quit IRC23:51

Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!