15:00:56 <xek> #startmeeting barbican
15:00:56 <opendevmeet> Meeting started Mon Feb 17 15:00:56 2025 UTC and is due to finish in 60 minutes.  The chair is xek. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:56 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:00:56 <opendevmeet> The meeting name has been set to 'barbican'
15:01:05 <xek> #topic Roll Call
15:01:13 <xek> Courtesy ping for dmendiza[m] ade_lee d34dh0r53 Luzi tosky tobias-urdin jjung mharley lpiwowar
15:01:20 <xek> rajiv o/
15:01:31 <xek> As usual our agenda can be found here:
15:01:46 <xek> #link https://etherpad.openstack.org/p/barbican-weekly-meeting
15:06:16 <rajiv> heylo
15:06:50 <xek> looks like we're the only ones here
15:06:59 <rajiv> oops
15:07:38 <rajiv> i guess i will need dmendiza[m] to answer my query ! ?
15:08:00 <dmendiza[m]> 🙋
15:08:04 <xek> o great :)
15:08:19 <xek> let's go over the agenda
15:08:24 <rajiv> :)
15:08:34 <xek> #topic Review Past Meeting Action Items
15:08:38 <xek> There were none
15:08:50 <xek> #topic Liaison Updates
15:09:35 <xek> Election nominations are this week
15:09:50 <xek> #link https://releases.openstack.org/epoxy/schedule.html
15:10:28 <xek> and feature freeze is next week
15:10:44 <xek> #topic Open Discussion
15:10:56 <xek> rajiv shoot away :)
15:11:41 <rajiv> thanks, while testing the old bug https://review.opendev.org/c/openstack/barbican/+/933461
15:11:57 <rajiv> i noticed the Thales device returns a CKR error
15:12:30 <rajiv> after sharing this bug with Thales, it was concluded : https://www.thalesdocs.com/gphsm/integrations/guides/openstack_barbican/index.html#configure-openstack-barbican-with-thales-luna-hsm-or-luna-cloud-hsm
15:12:53 <rajiv> the conclusion is mentioned in the NOTES section, could dmendiza[m] review this ?
15:13:31 <dmendiza[m]> What conclusion, sorry I'm not sure what you want me to look at there?
15:13:49 <xek> I think rajivmeant troubleshooting section?
15:16:09 <rajiv> Enter hmac_key_type and hmac_keygen_mechanism details only when generating a new HMAC key. If you are upgrading from a previous version and already have an HMAC key, these flags are not required.
15:16:40 <dmendiza[m]> Right, yeah, those are used for HMAC key generation.
15:16:43 <rajiv> I disabled these 2 flags in my barbican.conf since the keys were already generated : https://github.com/sapcc/helm-charts/blob/master/openstack/barbican/templates/etc/_secrets.conf.tpl#L23-L28
15:17:41 <rajiv> okay, so this configuration is fine ?
15:24:02 <dmendiza[m]> rajiv: I would set those flags regardless.  They won't get used and you don't have to go edit your template if you need them.
15:24:59 <rajiv> when i set those flags, barbican-api fails to create pkeks for new projects, i get an error
15:25:05 <rajiv> it works for older projects though
15:27:08 <dmendiza[m]> rajiv: That's weird and sounds like a bug.  Those options should not affect PKEK generation.
15:27:45 <rajiv> The Thales expert also confirmed the same while testing this on a devstack
15:28:53 <rajiv> i upgraded to hsm 771 in QA for a month, i also observed new project secret creations failed, i presumed it was env issue :D
15:29:49 <rajiv> would it be an issue to proceed without this flag ?
15:32:46 <dmendiza[m]> My apologies, my previous response is not quite right
15:33:05 <dmendiza[m]> hmac_keygen_mechnanism is only used for HMAC master key generation
15:33:29 <dmendiza[m]> but hmac_key_type is used for both generating the master HMAC and also looking for the master hmac afterwards whenever it needs to be used
15:33:34 <dmendiza[m]> it is part of the query sent to the HSM to find the key
15:33:39 <rajiv> np :)
15:34:01 <dmendiza[m]> when you don't set that option, then oslo.policy uses the default value of CKK_AES
15:34:22 <rajiv> correct, so these flags need to be enabled only for new installation or where there are no keys right ?
15:34:45 <dmendiza[m]> No, you need to set hmac_key_type to match the type of key you created
15:35:24 <dmendiza[m]> if you create your HMAC (e.g. by using barbican-manage hsm gen_mkek ) then you need to set that option to the correct value for your HSM and keep it set for every deployment.
15:35:27 <rajiv> okay, so disable hmac_keygen_mechnanism and enable hmac_key_type ?
15:35:40 <dmendiza[m]> Again, you're not "disabling" these options
15:36:00 <dmendiza[m]> when you remove them from barbican.conf you're telling barbican to use the default value
15:36:14 <dmendiza[m]> https://opendev.org/openstack/barbican/src/branch/master/barbican/plugin/crypto/p11_crypto.py#L78-L84
15:36:28 <dmendiza[m]> So, removing them from barbican.conf is the same as setting them to
15:36:35 <dmendiza[m]> hmac_key_type=CKK_AES
15:36:45 <dmendiza[m]> hmac_keygen_mechanism=CKM_AES_KEY_GEN
15:37:17 <dmendiza[m]> CKM_AES_KEY_GEN is only used for creating the HMAC key
15:37:21 <dmendiza[m]> but CKK_AES is part of the query
15:37:35 <dmendiza[m]> so your HMAC key in  your environment must also be a CKK_AES key
15:37:38 <dmendiza[m]> or your query will fail
15:38:30 <rajiv> okay, Thales guide proposes : hmac_key_type = CKK_GENERIC_SECRET
15:39:22 <dmendiza[m]> It depends on what you use for hmac_mechanism https://opendev.org/openstack/barbican/src/branch/master/barbican/plugin/crypto/p11_crypto.py#L85-L87
15:39:48 <dmendiza[m]> some devices let you use CKK_AES for CKM_SHA256_HMAC, and some other devices don't
15:40:49 <rajiv> okay, so its an issue with the device now ?
15:41:54 <rajiv> the device is unable to support hmac_key_type and hmac_keygen_mechanism ?
15:43:05 <dmendiza[m]> No
15:43:23 <rajiv> this was the error msg when all flags were set : P11CryptoPluginException: HSM returned response code: 0xc0 CKR_SIGNATURE_INVALID
15:43:54 <dmendiza[m]> If you set hmac_mechanism=CKK_GENERIC_SECRET and get an error related to HMACs, then likely your actual HMAC key does not match the type
15:44:21 <dmendiza[m]> yeah, what's going on in your environment is that your HMAC key is probably CKK_AES
15:44:29 <dmendiza[m]> so setting it to CKK_GENERIC_SECRET is wrong
15:44:33 <dmendiza[m]> and that's why it fails
15:44:58 <dmendiza[m]> or you have both a CKK_AES and a CKK_GENERIC_SECRET keys and you're choosing the wrong one
15:45:04 <rajiv> ah okay, CKK_AES was the value before this patch was merged
15:45:19 <rajiv> maybe you tested with CKK_GENERIC_SECRET on your device ?
15:45:40 <dmendiza[m]> yes, so when you create the HMAC key you choose the type
15:47:03 <rajiv> okay, thanks for the clarification, back to another round of testing :)
15:48:01 <rajiv> in the db i saw project field with kek_data having mechanism as CKM_AES_KEY_WRAP_KWP
15:48:05 <rajiv> so this is expected
15:48:26 <dmendiza[m]> I think I used CKK_AES ... not sure though, I'll have to go back and chec
15:48:28 <dmendiza[m]> *check
15:48:38 <rajiv> oh ok
15:48:47 <dmendiza[m]> I do have access to a Thales device with FIPS mode turned on now, so I can do some testing on my end
15:49:41 <rajiv> ah ok! i can share mine :D
15:52:33 <xek> ok, I guess we'll have more updates next week!
15:52:40 <xek> let's check the bug boards...
15:52:40 <rajiv> sure
15:52:56 <xek> #topic Bug Review
15:54:03 <xek> There were no new bugs reported since our last meeting
15:54:09 <xek> See y'all next week!
15:54:12 <xek> #endmeeting