18:02:47 #startmeeting keystone 18:02:48 Meeting started Tue Jan 5 18:02:47 2016 UTC and is due to finish in 60 minutes. The chair is stevemar. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:02:50 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 18:02:52 The meeting name has been set to 'keystone' 18:02:56 #link https://wiki.openstack.org/wiki/Meetings/KeystoneMeeting 18:02:58 gyee: ++ 18:03:01 agenda meeting ^ 18:03:12 it's just what i added last night :( 18:03:31 i'll leave time for open discussion, or we can end early 18:03:43 the first two are just announcements 18:03:51 #topic keystoneauth-saml2 has been retired 18:04:21 the repo is now empty, aside from a README, there are only no-op jobs running for it's CI 18:05:00 there were no releases of it, and we managed to roll the functionality into keystoneauth (by using setuptool's extras) 18:05:09 so it's dead, one less repo to review - yay 18:05:26 yay 18:05:31 \o/ 18:05:32 great! 18:05:47 thanks goes to the infra team for pushing that ahead 18:05:58 any questions about it? 18:06:22 no feelings involved, bye keystoneauth-saml2 18:06:29 cool 18:06:33 #topic midcycle 18:06:56 please make sure you've registered here: https://wiki.openstack.org/wiki/Sprints/KeystoneMitakaSprint - i'll add this to the channel's topic 18:07:11 stevemar: you mean IBM-midcycle :-) Will there be room for anyone else?? 18:07:25 security group midcycle is next week, as is barbican 18:07:35 shaleh: I was planning to attend it :-( 18:07:36 bknudson_: going to be in SA? 18:07:44 yeah, busy month for meetups 18:07:50 dolphm: I'll be at the security group midcycle in SA 18:07:54 shaleh: there are a few rackers coming too :P 18:08:37 i'm trying to get us food for each day we're there 18:08:40 for lunch 18:08:44 stevemar: our group should be booked by end of week. Guanf and I setup yesterday 18:08:45 no jamielennox :( 18:08:52 so PM me if you have dietary restrictions/allergies 18:09:03 IBM, Rackspace, Mirantis and HP are represented so far 18:09:11 bknudson_: i was hoping to combine it with another meeting, but that part has fallen through 18:09:24 shaleh: cool, just remember to update the page so i have a clear # on how many ppl are coming 18:09:30 next time in australia 18:09:39 bknudson_: ++ 18:09:40 bknudson_: i'm sure i can organize some space 18:09:46 stevemar how do you register? 18:09:47 new zealand 18:09:57 rderose: fill out the table here: https://wiki.openstack.org/wiki/Sprints/KeystoneMitakaSprint 18:10:16 rderose: or email me saying you're coming and i'll fill it out 18:10:39 stevemar: there's not actually any instructions on the wiki to tell people to add their names 18:10:52 ... 18:11:10 it's a sign up sheet, but sure, i can add a sentence 18:11:18 make sure to 18:11:31 lol 18:11:41 I want Pho for lunch 18:11:56 gyee: hard to cater that 18:12:06 18:12:26 gyee: I'll be there and I know some good pho places ;) 18:12:35 dolphm: there: https://wiki.openstack.org/wiki/Sprints/KeystoneMitakaSprint#Registration 18:12:56 diazjf, ++ 18:12:58 alright, moving on 18:13:09 spread the word to those who aren't here 18:13:20 #topic Mitaka-2 milestone 18:13:50 the due date is coming up quickly - the week of Jan 21 18:14:06 #link https://launchpad.net/keystone/+milestone/mitaka-2 18:14:25 there are some features that haven't been started or have slow progress 18:14:52 stevemar: can't reseller appear on that list? :( 18:15:19 htruta: no 18:15:46 htruta: there are a few blueprints related to multi-tenancy on the list 18:16:30 we've got a whole lot to do and we need lots of reviews in the next few weeks from folks that aren't proposing code 18:16:51 stevemar: ok. I'll keep on the reviews 18:16:57 stevemar: count me in 18:17:40 if you see a bug that should be fixed and it hasn't been triaged, please go ahead and triage it too 18:19:13 also, any feature that doesn't have code proposed by milestone-2 will be moved to N 18:19:33 this was already communicated earlier in the release 18:19:43 stevemar, so MFA will be pushed to N then? 18:19:54 gyee: that's on the agenda, we'll get to it 18:20:26 gyee: for now, i mean things that a) have been approved for M, and b) have no code 18:21:12 AFAIK - mfa hasn't landed it's spec yet 18:21:55 if someone has any questions about it, you can bug on -keystone 18:22:08 #topic MFA 18:22:11 let's talk MFA now 18:22:22 yeah spec is kinda late 18:22:31 gyee: you've recently +2'ed the spec, thoughts? 18:22:40 i'll admit i haven't looked at the latest revision 18:22:47 if it's marked as experimental then why not? 18:22:50 stevemar, the proposed impl should be fairly trivial 18:22:57 we cut a lot out from the original spec 18:23:15 bknudson_: review time taken away from features that were proposed earlier 18:23:24 the original proposal was three specs rolled into one 18:23:48 #link https://review.openstack.org/#/c/130376/ 18:24:17 do we review features in order that they were proposed? 18:24:23 it shouldn't take more than a weekend to get it implemented :) 18:24:43 gyee: pfft, tell that to our growing list of technical debt 18:25:27 gyee you'll agree to review the implementation? 18:25:36 stevemar, yes, I will 18:25:42 any one else? 18:25:55 stevemar, and other reviews 18:25:56 I'll review the changes 18:26:11 bknudson_: you eventually need to sleep 18:26:24 or recharge, whatever it is cyborgs do 18:26:25 stevemar: i have no problem reviewing it 18:26:25 there's always too much to do so I just prioritize 18:26:28 bknudson, make sure to download the google app and try it out too 18:26:31 stevemar: I can do it too 18:26:34 google authenticator app I mean 18:26:44 i've got the symantec app 18:27:06 alright 18:27:06 that should work too 18:27:22 bknudson_: take a look a the spec then 18:27:34 dstanek: you too 18:27:35 will do 18:28:00 give it the old 2x +2 and +A treatment 18:28:09 bknudson_: no, symantec is weird and different 18:28:48 jamielennox, oh? you ran into interop issues? 18:29:08 you do know that the way auth plugins work in keystone this wont work as proposed? 18:29:16 this isn't totp 18:29:21 at all 18:30:01 the symantec VIP does some sort of registration with their service to exchange hashes and then you get an ID in the app and exchange - not the hash 18:30:09 the issue is you need a new plugin that requires both totp and password not the password,totp 18:30:11 the only reason i can see for this is so that they can bill per user 18:30:16 a wild notmorgan appears... explain your concerns please 18:30:30 as, even as described in the spec if one plugin passes, the auth is successful 18:30:38 nope 18:30:40 this means as proposed you can auth ONLY with totp 18:30:47 all methods has to pass 18:30:51 gyee: no 18:31:05 that is not how it has been implemented at least unles someone changed it 18:31:07 you CAN auth with totp only 18:31:15 then i am -2 on the spec 18:31:18 gyee: * If one matches, the authentication is considered successful 18:31:24 but if both methods are specified, all has to pass 18:31:59 once we get a totp implementation we can refine it. 18:32:22 notmorgan: that is a small bit of spec refinement to ensure AND, not OR 18:32:34 notmorgan: your concern of it working at all is a bigger one 18:32:48 this weakens keystone's auth 18:32:52 if used 18:33:30 how does that weaken keystone auth? 18:33:31 if the user can specify either password, or totp, or whatever 18:33:37 that is not adding MFA in at all 18:34:17 even totp by itself is a hell lot better than a static password 18:34:56 like I said, that was a 3 spec deal 18:35:17 the other spec will mandate the methods used for a given user/project/domain 18:35:18 i am -2 for that spec as is, the same as I was when the same thing was proposed before 18:35:38 sorry 18:35:50 that existing spec is just the plugin itself 18:35:56 the spec as it is proposed 18:36:31 it should be part of the password plugin not a separate plugin the user *must* add in like password,totp with the separate sections 18:36:41 if you want to call it MFA, make it mfa 18:37:01 if you want to just implement a totp auth plugin, that isn't what this spec is 18:37:22 it wouldn't be a password plugin 18:37:32 it is part of the password auth. 18:37:50 MFA is a concept 18:37:54 this is not MFA 18:37:54 doesn't have to be a password 18:38:02 this is "other ways to auth" 18:38:24 notmorgan: where are you reading that you don't need to authenticate all methods in a auth request? 18:38:30 it could be a combination of 2 - n factors 18:38:34 impl various 18:38:48 as far as I know there's no way to say that a user must auth with password and totp 18:38:57 jamielennox: when i looked into this before when it was proposed auth is just bizzarly implemented within keystone 18:39:06 notmorgan: i don't know if this weakens it other than to give a false sense of security 18:39:15 bknudson_, you can't, MFA does not tied to passwords 18:39:24 dstanek: i equate false sense of secutiry to weaken 18:39:47 gyee: password was an example. there's no way to say that a user must auth with both x and y methods. 18:39:55 so do we need 'mfa' plugin that calls out to password and totp? 18:39:55 there's no false sense, the methods are in the token data 18:39:56 bknudson_: ++ 18:40:00 bknudson_: policy should be able to say that 18:40:07 why doesn't the new mfa plugin accept the password and token; and then behind the scenes validate them both? 18:40:07 so i think it was the ebay group that wanted to add to keystone that for some projects you needed to have certain forms of auth, this would be a precursor to that 18:40:08 notmorgan: fair point 18:40:12 dolphm: that would be cool 18:40:15 so if someone wants to propose that side, i'd support it 18:40:17 bknudson_: "role:admin and factors:2" or something 18:40:30 bknudson_, that will be in the second spec, tied the auth methods with the user/project/domain, like I said before 18:40:34 but i don't support this spec. i didn't support this spec when it was implemented before 18:40:40 s/implemented/proposed/ 18:40:59 gyee: I'm fine with it being a separate spec. 18:41:14 notmorgan: could this spec be adjusted with the understanding that it is laying groundwork and not the final goal? 18:41:18 dolphm, right, you can authz with policy as well, given we have the aut methods in the headers 18:41:21 this spec is "add a totp auth method", which seems absurd as a spec 18:41:57 well without more detail on where the secrets live etc 18:42:09 notmorgan, how is it absurd? totp is a hell lot better than passwords 18:42:25 secrets comes from credentials 18:42:49 gyee: the spec says it needs to store user secrets but is not clear on where or how 18:42:50 notmorgan: the secrets are stored in /v3/credentials 18:42:50 the 3rd spec would be to roll a credentials backend for barbican 18:42:56 stevemar: oh god 18:43:10 stevemar: terrible place to store it :( 18:43:20 i don't think keystone can rely on barbican 18:43:30 but w/e 18:43:30 I am not saying we will 18:43:33 jamielennox: the current spec removed the barbican requirement 18:43:41 credential backends are pluggable, just like any backends 18:44:01 hell you can roll a credential backend for your favorite ESKM :) 18:44:11 so this spec does not cover MFA, this spec sortof kindof says it's adding totp as a method of authentication 18:44:18 so, i stand by the -2 18:44:36 notmorgan: what would it take to change that to a +2? 18:44:49 it lays the ground work for MFA, so if we want to play with the wording 18:44:55 if you want to change the spec and make it clear it is only adding a totp auth method and clarify where the secrets are stored/generated/etc? 18:45:06 i'd -1 it instead 18:45:13 stevemar: u can't have secrets for totp stored in plain text in /v3/cred table just like we store key pairs 18:45:16 is it a matter of changing from 'adding mfa' to 'adding totp'? mfa comes later in another spec ? 18:45:16 sure, I can update it to make it more clear 18:45:22 do not call it mfa 18:45:26 this is not mfa 18:45:32 like I said, this is a 3 spec deal 18:45:39 haneef: that's another good point :( 18:45:41 to get what we really wanted 18:45:42 i think you're doing this the wrong way 18:45:47 you should fix the other side of this first 18:45:48 gyee: refer to haneef's comment 18:45:55 gyee: the spec does not explain that it is 1 of 3. 18:45:55 haneef, the spec said we encrypt it 18:46:06 master key is configurable 18:46:10 gyee: "we swear we will ecrypt this" 18:46:16 i really don't think this spec is baked 18:46:29 static master key isn't really much better. 18:46:42 but enough to dodge the "this is plain text" argument 18:46:45 notmorgan: agreed. Which is why I am asking for how to help the submitter get to a good position. 18:46:53 whahhh? are we saying fernet keys are no good?! :) 18:47:01 duuuude 18:47:08 lets be realistic here 18:47:15 gyee: totp keys aren't rotated 18:47:17 in most cases 18:47:26 they can be rotated via cred apis 18:47:38 gyee: no one does that 18:47:40 * ayoung shows up late 18:47:46 huh? 18:47:51 ok anyway so here is what you need for me to lift the -2 from this spec 18:48:01 APIs are there, what do you mean no one does that 18:48:07 no one rotate fernet keys? 18:48:08 1) either fix it to address adding MFA support not just TOTP auth plugin 18:48:17 if their compliance officer as them to, they better 18:48:25 gyee: if MFA is a 3 part spec, then this would seem to be the simplest part of MFA. why not attempt one of the other parts first ? 18:48:34 or 2) make it about just adding totp as an auth method and clarify the secret storing/generation/etc 18:48:48 and at that point i'll move my -2 to a -1 18:49:01 and let stevemar determine if it is baked enough to land 18:49:08 gyee: when was the last time you changed your google authenticator totp key? it's only when you change devices 18:49:30 i'm not sure i understand what secret it wants to store 18:49:35 jamielennox, I've got emails form my IT department to change my password every 3 froggin months 18:49:43 if you want to address the MFA suport (vs just adding an auth plugin) I'd consider dropping the -2 to a no-score 18:49:52 gyee: right, but never to change your 2fa PSK 18:50:02 dstanek: if it's doing TOTP the server needs to know the shared secert 18:50:12 jamielennox, if my IT department mandates it, I have no choice 18:50:13 dstanek: to make sure your HMAC+time offset is sane 18:50:16 whether I like it or not 18:50:17 does this want to create its own want to do totp instead of using something like rsa? 18:50:35 dstanek: TOTP is a well defined algorithm 18:50:37 compliance is non-negotiable 18:50:51 dstanek: regardless of the implementation 18:51:10 notmorgan: sure, but if we are implementing then there are lots of details missing 18:51:13 dstanek: if it is doing RSA proprietary it'll need to talk to the RSA device 18:51:36 anyway, let me touch up that spec and we'll go from there 18:52:26 is nonameentername here? 18:53:16 doesn't look like it 18:53:31 if we get this working, he owe me Pho 18:53:56 he'll owe you his first born 18:54:10 hah 18:54:26 gyee: that's too much work, just ask for the Pho 18:54:46 ++ 18:54:47 quick topic change while we still have 6 minutes 18:54:53 #topic Deprecating python-keystoneclient-kerberos 18:55:06 i talked to jamielennox and bknudson_ about this, there's no reason to keep it around 18:55:13 the logic is in keystoneauth now 18:55:13 yeah, see I told you ayoung. No one uses kerberos :-) 18:55:21 hehe 18:55:26 keystoneauth is the greates 18:55:28 greates 18:55:30 shaleh, not true...but that plugin is not needed as is 18:55:31 greatest 18:55:37 we need negotiate on the session, 18:55:48 so auth pluginis just a generic Federatation plugin 18:56:01 ayoung: i think keystoneauth has all the patches you are looking for 18:56:06 ayoung, tell these guys the keytabs are not encrypted :) 18:56:26 gyee, tell who that? 18:56:53 looks like django-openstack-auth is the only library that uses keystone-kerberos, jamielennox i think you created DOA? 18:56:59 err... DOA-kerb 18:57:15 yeah, DOA-kerb is jamie's work 18:57:34 If DOA-kerb stopped using it then that would be easier to justify removing it 18:57:40 we need to deprecate ksc-kerb and migrate DOA-kerb to use ksa 18:57:41 stevemar: yea, it's essentially the same deal as ksc-kerberos, we didn't want DOA to have a direct dependency on kerberos libs 18:57:45 ayoung, I was referring to the unencrypted creds discussion we had earlier 18:58:02 Keytabs are unencrypted 18:58:04 AFAIK there has not been a similar discussion in DOA about using extras, lhcheng_ might know 18:58:12 there I told them 18:58:31 * gyee high-5s ayoung 18:58:43 stevemar: but doa-kerb can easily be made to use ksa-kerberos (though i don't think it's been ported to ksa yet) 18:58:52 gyee: but totp keys are not rotated in most cases and doing a master key rotation via the API is not even discussed 18:58:53 ah, sorry ksa[kerberos] 18:58:54 so... 18:58:59 jamielennox: it has 18:59:16 stevemar: really? then doa-kerberos is broken anywa 18:59:18 y 18:59:29 jamielennox: ? 18:59:34 bah, out of time 18:59:39 thanks everyone 18:59:44 #endmeeting