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