13:01:41 <redrobot> #startmeeting barbican
13:01:42 <openstack> Meeting started Tue Jan 15 13:01:41 2019 UTC and is due to finish in 60 minutes.  The chair is redrobot. Information about MeetBot at http://wiki.debian.org/MeetBot.
13:01:43 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
13:01:46 <openstack> The meeting name has been set to 'barbican'
13:02:02 <Luzi> o/
13:02:06 <graeb> o/
13:02:39 <moguimar> o/
13:02:53 <moguimar> back from lunch just in time =D
13:03:41 <redrobot> #topic Roll Call
13:03:47 <redrobot> Courtesy ping for ade_lee hrybacki jamespage Luzi lxkong moguimar raildo rm_work xek
13:03:53 <redrobot> moguimar, nice
13:04:03 <raildo> o/
13:04:31 <redrobot> Sweet, let's get started
13:04:38 <jaosorior> o/
13:04:47 <redrobot> #topic Review action items from last week
13:05:03 <graeb> I successfully tested patch for SafeNet HSM (see https://review.openstack.org/#/c/629294/). Thank you very much for the work!
13:05:36 <redrobot> graeb, awesome!  Glad we were able to unbreak you guys
13:05:42 <graeb> Nevertheless I would like to stress one more time, that I am thinking, that generation of PKEKs with attribute CKA_SENSITIVE set to false may decreases security. As redrobot in the last meeting already mentioned, PKEKs get wrapped immediately after generation. But if my code analysis are correct, PKEKs stay in HSM memory after generation with attribute CKA_SENSITIVE set to false and will be used that way until they gets cleared out of the HSMs
13:05:42 <graeb> memory and need to be unwrapped again. Therefore setting the default for the new configuration parameter always_set_cka_sensitive to true was a good decision. Thanks again!
13:05:46 <redrobot> first action item:
13:06:02 <redrobot> redrobot to update the Barbican Wiki page
13:06:04 <redrobot> I did not do that
13:06:06 <redrobot> so let's punt
13:06:09 <redrobot> #action redrobot to update the Barbican Wiki page
13:06:30 <redrobot> Next: redrobot to ask alee about submitting the Barbican workshop to the next Summit
13:06:54 <redrobot> I did remind ade_lee that we've got the Summit CFP deadline coming up, but didn't ask about the workshop specifically
13:06:57 <redrobot> so punt!
13:07:07 <redrobot> #action redrobot to ask alee about submitting the Barbican workshop to the next Summit
13:07:38 <redrobot> graeb, I'll add an item to the agenda to talk about that
13:07:56 <graeb> redrobot, thx
13:09:22 <redrobot> ok, moving on
13:09:31 <redrobot> thanks Luzi and graeb for using the agenda etherpad
13:09:52 <redrobot> #topic Successfully tested regression fix patch for SafeNet HSM
13:10:04 <redrobot> #link https://review.openstack.org/#/c/629294/
13:10:08 <openstackgerrit> Merged openstack/barbican master: Replace tripleo-scenario002-multinode with scenario002-standalone  https://review.openstack.org/628244
13:10:44 <graeb> I was to fast, sorry, First point already mentioned. Second is, we found a new bug:  "ERROR: _get_master_key() takes exactly 3 arguments (2 given)" when executing `barbican-manage hsm rewrap_pkek`
13:11:29 <redrobot> RE: graeb's concern above
13:11:48 <redrobot> Some HSMs actually require that CKA_SENSITIVE=False when CKA_EXTRACTABLE=True
13:12:09 <redrobot> The spec is not very clear on the relationship between the two
13:12:19 <graeb> Jep. Nothing we can do
13:12:30 <redrobot> hence the disagreement between what the Safenet HSM does and what these other HSMs are doing.
13:12:44 <redrobot> ok, moving on
13:12:58 <redrobot> #topic Bug "ERROR: _get_master_key() takes exactly 3 arguments (2 given)" when executing `barbican-manage hsm rewrap_pkek` (Luzi, graeb)
13:13:20 <graeb> I think nothing more to say here?
13:13:42 <graeb> It's clearly a bug. Tested also with two different HSMs.
13:14:50 <Luzi> Safenet and Utimaco Soft HSM are the ones we test with
13:15:41 <redrobot> Yeah, sounds like we forgot to update wrap_pkek when we changed things to use configurable mechanisms
13:15:47 <redrobot> should be a striaghtforward fix
13:15:57 <redrobot> graeb, Luzi did y'all add a Story yet?
13:16:02 <graeb> No
13:16:14 <Luzi> will do it, after the meeting
13:16:26 <graeb> luzi, thx
13:17:15 <redrobot> Cool
13:17:37 <redrobot> Luzi, thanks, please post the link in the IRC channel after you open it.  I'll see about getting that fixed
13:17:49 <Luzi> redrobot, okay :)
13:18:08 <redrobot> #action Luzi to add a new story to the Barbican Storyboard for the _get_master_key() error
13:19:46 <redrobot> #topic Why do we SHA256 HMAC over a wrapped PKEK?
13:19:59 <graeb> We have problems with a HSM (emulator) from Utimaco. If a new PKEK gets generated, Barbican computes a HMAC of the wrapped PKEK (and its initialization vector) using CKM_SHA256_HMAC. Barbican throws a traceback with error CKR_MECHANISM_INVALID. We already in touch with Utimaco. One of their system engineers suggested to replace CKM_SHA256_HMAC by CKM_AES_MAC, which works. The problem now is, that the HMAC, that will be generated is just 64 bits
13:19:59 <graeb> long instead of 256 bits. So i was just wondering, whether Barbican becomes less secure because of that and that the reason for computing a HMAC of wrapped PKEKs actually is?
13:22:55 <redrobot> So, we calculate an HMAC to guarantee integrity of the data
13:23:17 <redrobot> e.g. an hmac would fail if the ciphertext for the PKEK becomes corrupted
13:23:45 <graeb> Ok, but why secure it with an Key?
13:24:37 <graeb> For integrity reasons makes sense to me. But don't know why encrypting the signature.
13:24:57 <redrobot> So, HMAC does use a key
13:25:11 <redrobot> and the signature is not sensitive material
13:25:16 <redrobot> so there's no need to encrypt that
13:27:36 <mhen> so, the difference between 256 and 64 bit HMAC is only how frequent collisions are?
13:27:45 <mhen> (sorry for barging in suddenly)
13:28:04 <redrobot> I'm not 100% on how AES HMAC works
13:28:12 <redrobot> no worries mhen
13:28:29 <redrobot> we always appreciate input from smart folks
13:28:31 <redrobot> :D
13:29:01 <graeb> So its just a compatibility issue with Utimaco HSMs. What to do about it?
13:30:51 <redrobot> graeb, yeah, we'll need to make that HMAC wrap a configurable mechanism as weel
13:30:53 <redrobot> *well
13:31:24 <graeb> Sounds good. :-D Shall I add a story?
13:32:06 <redrobot> graeb, yes, please
13:32:20 <redrobot> #action graeb to add story for making HMAC Key Wrap mechanism configurable
13:32:28 <graeb> redrobot, thanks I will do after the meeting.
13:32:42 <redrobot> #topic Failing Gates
13:32:51 <redrobot> I'm sure you noticed the gates were failing all last week.
13:33:07 <redrobot> We ended up merging a workaround yesterday
13:33:22 <redrobot> #link https://review.openstack.org/#/c/628667/
13:33:48 <redrobot> To undo the workaround we're going to need to rewrite the paging/quota tests so that there are no race conditions when run in parallel
13:34:03 <redrobot> We'll also need to figure out why grenade is failing
13:35:49 <redrobot> Maybe I should add some stories for those
13:36:07 <redrobot> #action redrobot to add stories for permanent fixes to the gate workarounds
13:36:40 <redrobot> We should be back in business now, so I'll be rebasing patches to get the patch backlog down
13:37:40 <redrobot> any questions about the workaround?
13:38:49 <redrobot> Ok, that's all the topics I had for today
13:38:56 <redrobot> any last minute topics y'all want to talk about?
13:40:35 <redrobot> I'm gonna take that as a no
13:40:45 <redrobot> thanks for coming everyone!
13:40:49 <redrobot> #endmeeting