IETF
kitten
kitten@jabber.ietf.org
Thursday, March 6, 2014< ^ >
stpeter has set the subject to: KITTEN WG | http://tools.ietf.org/wg/kitten/
Room Configuration
Room Occupants

GMT+0
[15:06:56] tlyu@mit.edu joins the room
[15:10:05] Steve Olshansky joins the room
[15:11:19] jimsch1 joins the room
[15:15:49] kaduk@jabber.openafs.org/barnowl joins the room
[15:20:14] scottcantor@jabber.org joins the room
[15:21:31] derek joins the room
[15:22:29] <derek> Can people hear Shawn?
[15:22:30] <jimsch1> it sounds good
[15:22:31] <scottcantor@jabber.org> yes
[15:22:33] <kaduk@jabber.openafs.org/barnowl> Hi Shawn.
[15:22:53] <derek> Thanks..  Message relayed.   I'll be relaying Jabber Questions/Statements to the Mic.
[15:22:59] Zash joins the room
[15:23:00] nico joins the room
[15:23:06] <nico> hi
[15:23:27] m&m joins the room
[15:24:18] m.jenkins.364706 joins the room
[15:24:50] ghudson joins the room
[15:25:21] sftcd joins the room
[15:25:27] <nico> audio works
[15:25:28] Karen O'Donoghue joins the room
[15:26:24] <derek> tlyu@mit.edu: Did you publish?
[15:26:30] <tlyu@mit.edu> registries not yet ready for validation, but some portions might be soon
[15:26:55] <kaduk@jabber.openafs.org/barnowl> (I had previously volunteered to look at registries and still can)
[15:27:00] satoru.kanno@jabber.org joins the room
[15:27:10] oej joins the room
[15:27:12] linus joins the room
[15:28:18] <tlyu@mit.edu> would be helpful if chairs would work with me on scheduling the work
[15:29:27] idra joins the room
[15:29:34] <scottcantor@jabber.org> thank you
[15:29:41] <nico> I did a while back
[15:29:59] <nico> I will read it again
[15:30:16] nicolson joins the room
[15:32:16] <jimsch1> Mike: IAKERB should be ready for last call
[15:33:02] <ghudson> Did you get my feedback on it?
[15:33:21] <derek> greg, is that for the room or to someone?
[15:33:26] <ghudson> For Jim.
[15:33:30] <derek> k
[15:34:04] Adam Bishop joins the room
[15:34:15] satoru.kanno@jabber.org joins the room
[15:34:22] <nico> why would it not be ok to put AD-CAMMAC in AD-IF-RELEVANT?
[15:34:22] satoru.kanno@jabber.org leaves the room
[15:34:30] <nico> (no need to ask on mic)
[15:34:50] <nico> np
[15:34:58] <oej> Suggestion: Prefix with "mic:" when you need a relay to the room…
[15:35:05] <tlyu@mit.edu> mic: we can take it to the list, i think
[15:35:06] <oej> (No need for mic on that either)
[15:35:09] <nico> at least I now know that the audio delay is not tens of seconds!
[15:35:12] <jimsch1> greg: need to run the list again - but I have not seen any
[15:35:38] <derek> okay, i will only relay messages that begin "mic:"
[15:35:45] <nico> :)
[15:35:56] <kaduk@jabber.openafs.org/barnowl> jimsch1: I had made some editorial comments on the iakerb -00 a while ago as
well.
[15:36:00] <ghudson> jimsch1: Look for two messages with the subject "Comments on draft-ietf-kitten-iakerb-01" on the kitten list.
[15:36:19] <jimsch1> greg:  I think I got all of the -00, will look for the -01
[15:36:43] <nico> implementations of IAKERB?
[15:36:53] <ghudson> I think maybe GS2?
[15:37:01] <derek> sasl-gs2
[15:37:03] <nico> I think there's two-ish
[15:37:41] <nico> I thought he did
[15:38:14] <oej> Hannes tschofenig with mic in hand
[15:39:21] <oej> Agenda and slides: https://tools.ietf.org/wg/kitten/agenda
[15:39:27] <nico> for the record, I really like Simon's GS2-bis
[15:43:41] <nico> mic: so it seems to me that OAuth's SASL bindings should not require carrying anything else besides the authz-id.  Any other IDs would have to already be inside the OAuth token
[15:44:13] <nico> mic: to answer Sam's question about whether it'd be OK to carry an unprotected authzid, see also Simon's GS2-bis I-D
[15:45:15] <nico> mic: Sam, yoiu just said that this stuff would have to be inside the OAuth token, which was what I'd said
[15:45:41] <nico> mic: I agree to help resolve this
[15:46:18] <nico> mic: right, sure, we're using our terminology here
[15:47:06] <nico> mic: I'm saying the user= thing is either superfluous or it's the authzid
[15:47:17] <nico> necessarily
[15:47:27] <scottcantor@jabber.org> FWIW, I agree, I have yet to see any explanation that leads me to think it's not the authzid
[15:48:39] <nico> because a) SASL doesn't speak of carrying anything other than the authz-id (SASL has no concept of authorization-data), b) anything like an authenticated ID comes from the internals of the mechanism
[15:49:05] <derek> nico: is that for the mic?
[15:49:10] <nico> derek: yes, sorry
[15:50:09] <nico> mic: a routing hint that the app needs to be aware of would be a bit of a change to SASL!  while a routing hint for the mechanism is an internal detail
[15:51:16] <nico> so if it's a routing hint rename the thing from "user=" eh?  :)  (no mic)
[15:51:20] <tlyu@mit.edu> bullet on slide seems reversed (CBC vs CTS)
[15:51:40] <tlyu@mit.edu> mic on that last comment, sorry
[15:52:07] <ghudson> Where are the slides?
[15:52:19] <tlyu@mit.edu> http://www.ietf.org/proceedings/89/slides/slides-89-kitten-0.pdf
[15:52:30] <kaduk@jabber.openafs.org/barnowl> linked from https://tools.ietf.org/wg/kitten/agenda
[15:52:31] <nico> heh
[15:52:35] <oej> Slide #13 now
[15:52:40] <oej> Slide #14
[15:52:41] <kaduk@jabber.openafs.org/barnowl> (There are decks for s4u and the java updates as well)
[15:52:45] <jimsch1> Materials page for the est of them https://datatracker.ietf.org/meeting/89/materials.html#sec
[15:52:49] <m.jenkins.364706> we'll make the changes and post to the list soon.
[15:52:55] Karen O'Donoghue leaves the room
[15:54:30] <nico> how can this be a standard without making RFC4120 a standard?
[15:54:44] <nico> mic that
[15:54:50] <kaduk@jabber.openafs.org/barnowl> Yeah, I thought there were dependency issues (no mic).
[15:54:50] <nico> pls
[15:54:52] <nico> :)
[15:55:22] <nico> if we can, then sure
[15:55:34] cw joins the room
[15:55:50] m.jenkins.364706 leaves the room: Disconnected: Replaced by new connection
[15:55:51] m.jenkins.364706 joins the room
[15:56:08] <nico> thanks :)
[15:56:47] <nico> I couldn't answer that last right now
[15:57:01] <kaduk@jabber.openafs.org/barnowl> Yeah, that sounds like a question for the list.
[15:57:25] <oej> Slide #15
[15:57:30] <oej> RFC 4402 Issue
[15:57:30] <kaduk@jabber.openafs.org/barnowl> mic: (4402) you stop when you have enough bits, it doesn't matter n or
n-1, really.
[15:57:49] <kaduk@jabber.openafs.org/barnowl> (possibly delayed mic)
[15:58:39] Karen O'Donoghue joins the room
[15:59:07] <ghudson> mic: Heimdal starts at zero, like MIT
[15:59:13] <nico> Heimdal and MIT now agree
[15:59:13] <kaduk@jabber.openafs.org/barnowl> mic: AFS's rxgk spec is using the PRF+ from 4402, starting at 1, but
there is no interoperability concern because it's not a gss mech.
[15:59:36] <ghudson> mic: I think I looked and found it likely that there are no other implementations.
[16:00:07] <nico> I can edit the update
[16:01:04] <ghudson> nico: Did you see that I sent test vectors?
[16:01:11] <nico> ghudson: yes
[16:01:31] <nico> I didn't test them; I'll make sure Heimdal has a test using those vectors
[16:01:56] <oej> New presenter: Viktor Dukhovni
[16:02:29] <oej> Slide #1
[16:02:38] <oej> Slide #2
[16:06:31] <idra> mic: you chould never depend on reverse resolution anyway
[16:06:47] <idra> (it is always broken in most depoyments anyway)
[16:06:53] <ghudson> We would absolutely turn that off by default if we didn't think it would cause pain for existing deployments, and we recommend setting rdns=false for new deployments.
[16:07:03] <ghudson> 4120 actually says you shouldn't even do forward resolution.
[16:07:07] <ghudson> (No need to mic.)
[16:07:23] <idra> idra = Simo Sorce
[16:07:25] <idra> :)
[16:07:26] <m&m> idra: real name for minutes?
[16:07:27] <m&m> thanks
[16:08:18] oej leaves the room
[16:08:33] <idra> fwiw it would be exteremly simple for FreeIPA to implemnt this method, so I am opening tickets in a few minutes
[16:08:59] <derek> idra: nice to meet you "in person"  :)
[16:09:06] <idra> heh
[16:09:40] <derek> ghudson: how about a configure option in MIT Krb5 --disable-rdns?  ;)
[16:09:48] Karen O'Donoghue leaves the room
[16:09:50] <ghudson> I think we might have that already.
[16:09:59] <ghudson> Maybe we don't.
[16:10:27] <derek>   --enable-dns-for-realm  enable DNS lookups of Kerberos realm names
[16:10:43] <derek> That's the only thing I see with configure --help | grep -i dns
[16:11:04] <ghudson> We have DEFAULT_RDNS_LOOKUP but maybe no configure option for it.
[16:11:07] <nico> mic: if MSFT is doing this widely then we might just have to standardize it :(
[16:11:20] <kaduk@jabber.openafs.org/barnowl> There is a little bit of strangeness w.r.t. DNS and configure, but I
shouldn't look right now.
[16:13:36] <idra> mic: why should you key the CNAME ?
[16:14:05] <ghudson> 4120 disallows any DNS lookup of the service name.  (No mic.)
[16:14:22] <nico> mic: well, when CNAMEs cross boundaries the idea is that the KDC must know this too and issue a referral
[16:14:26] <derek> idra: do you still want me to forward that?
[16:14:43] <idra> yes
[16:14:48] <nico> idra: you must key the cname because you're not supposed to chase the CNAME during name canon
[16:15:52] <idra> nico: ok except we always chase CNAMEs in MIT (and afaik Heimdal), so interesting problem
[16:16:12] <nico> idra: I know; first we must make sure that CNAMEs get keyed
[16:16:13] <tlyu@mit.edu> idra: i thought we added an option to turn off forward resolution
[16:16:17] <nico> we'll get there
[16:16:33] <derek> I have a quick S4U2Proxy question:  is the result of S4U2Proxy a standard service ticket (effectively just like I'd get from a normal TGS Req) or must I combine the results with the TGT when making an AP-REQ with it?
[16:16:38] wmills_92105 joins the room
[16:16:56] <idra> derek, standard ticket
[16:17:59] <derek> irda: thanks.  thought so, but wanted to verify from the experts.
[16:18:41] m&m leaves the room
[16:18:44] m&m joins the room
[16:22:02] <kaduk@jabber.openafs.org/barnowl> This seems sort of reminiscent of some oauth-type control flows, with
servers authenticating to each other, and user information carried
somewhat out-of-band.
[16:22:36] <nico> kaduk: it's inspired by SASL's notion of authzid
[16:22:36] <idra> mic: I find this delegeation mechanism very flawed, it combines s4u2self and s4u2proxy in one effectively, w/o involvement of the KDC, allowing an application to *always* impersonate a user, even if the user never contacted the first forwarder in the first place. This is completely missing from the drafts security considerations btw
[16:22:38] <derek> it also seems to imply you need to rework *every* server to look for the name-auth.
[16:22:59] <idra> mic: I understand you mention the option, but you do not really seem to support it as a requirement
[16:23:03] <nico> idra: this works with S4U2Self, but it doesn't require it
[16:23:12] <nico> idra: and it doesn't "combine" it
[16:23:29] nicolson leaves the room
[16:23:36] <nico> (mic) sam: because existing apps tend to know how to deal with principal names (well, ours anyways)
[16:23:45] <idra> nico: it combines the concepts, because an application just goes ahead and impersonate any random user it wants if an evidence ticket is not required
[16:24:18] <nico> idra: you missed the point; think of SASL
[16:24:40] <idra> I just do not agree with your conclusions, I think I understand what you are proposing
[16:24:51] pspacek joins the room
[16:24:59] <nico> idra: if it's OK for SASL to have an authzid concept, then it ought to be OK here as well
[16:25:09] <nico> idra: applications that don't understand this fail safe
[16:25:16] <nico> because they see the impersonator's name
[16:25:22] <idra> fail safe is just a red herring to me
[16:25:26] <ghudson> derek: Conceivably the GSS acceptor library could convert the authenticated client name if it sees a KDC-blessed impersonated user ID.
[16:25:35] <ghudson> I guess that's not consistent with the draft.
[16:25:43] <ghudson> Since the draft specifies using a name attribute.
[16:26:07] <nico> the draft does say that getting the KDC out of it is the point
[16:26:55] <idra> mic: for our scenarios KDC control is fundamental
[16:27:15] oej joins the room
[16:27:24] <ghudson> The draft does allow the KDC to "bless" the authorization data and for servers to require that.
[16:27:37] <ghudson> Although that doesn't sound like Viktor's use case.
[16:27:55] <nico> mic: but also, just as in the SASL case, and in the Kerberos transited policy case, this belongs in the target app!
[16:27:59] oej leaves the room
[16:28:06] linus leaves the room
[16:28:09] <idra> actually in MS world you know the transit paths, they are available in the MS
[16:28:17] <idra> in the MS-PAC for the app to read
[16:28:21] <scottcantor@jabber.org> as Greg just said, nothing stops you from backing this with "proofs" from the tokens that authorize the delegation more securely than just "because I say so"
[16:28:34] <nico> idra: there's no proposal to obsolete S4U2Proxy (which isn't even an Internet Proposed Standard)
[16:28:52] <idra> mic: I think my main problem is the lack of evidence ticket, anything else is just a deployment prefernce
[16:29:09] <nico> mic: the principle here is to follow the existing precedent for transited policy
[16:29:23] Adam Bishop leaves the room
[16:30:25] <scottcantor@jabber.org> very interested in this
[16:30:42] <idra> there are 2 unread mics :)
[16:31:18] <derek> did i miss any?
[16:31:21] <m&m> this is quite an exciting session!
[16:31:34] <scottcantor@jabber.org> yes
[16:31:39] pspacek leaves the room
[16:31:41] <sftcd> yeah, new real work is good
[16:31:44] <kaduk@jabber.openafs.org/barnowl> I plan to read the drafts when I get time.
[16:31:46] <nico> mic: that precedent is: the KDC can contribute its policy, but the target service has the final say
[16:31:47] <idra> yes, because this will cause me a lot of work if approved :)
[16:31:59] <idra> (yes as in: I will review)
[16:32:13] <Zash> m&m: What am I missing? :)
[16:32:34] <idra> mic: when there 2 competing mechanism you have half apps using one and half using the other, this is an interoperability problem
[16:33:06] <m&m> Zash: everything! (-:
[16:33:27] <scottcantor@jabber.org> mic: the benefit is this mechanism surfaces the information indifferent to GSS mech
[16:33:45] <derek> have I missed anything?
[16:33:55] <idra> seem all
[16:33:56] <wmills_92105> I think you are up to date
[16:34:03] <nico> scottcantor: indeed!
[16:34:05] <derek> phew.   That was a lot.
[16:34:11] <kaduk@jabber.openafs.org/barnowl> Thank you for performing the protocol translation for us, Derek!
[16:34:13] <nico> derek: :)
[16:34:23] <derek> My pleasure..  Hard to do that *and* speak for myself  ;)
[16:34:29] <scottcantor@jabber.org> nice job
[16:34:30] <idra> mic: not really if you have 2 hops
[16:34:40] <nico> derek: ah, you were chanelling yourself; I wasn't sure
[16:34:43] <idra> mic: you see only the last application if I read it right
[16:34:43] <wmills_92105> during the OAuth/SASL discussion id the GS2 question form my mail come up?
[16:34:55] <tlyu@mit.edu> mic: i'm biased against having another way to do something that we already have a way to do, but i can see why this new approach might be important
[16:35:20] <idra> mic: only if you have crypto evidence, which you say is optional
[16:35:27] <scottcantor@jabber.org> we don't have a way though, transparent impersonation != delegation
[16:35:36] <ghudson> (No need to mic) I'm also concerned about muddying the waters; I wonder if Microsoft has a solution for the routing loop issue.
[16:35:38] <nico> idra: crypto evidence in Kerberos loses value as you cross realms
[16:35:51] <nico> heh
[16:36:03] <derek> sorry, guys... going to the list for this topic now
[16:36:03] <nico> thanks
[16:36:15] <idra> derek, it's were we need to go indeed
[16:36:30] <derek> true
[16:37:12] <kaduk@jabber.openafs.org/barnowl> Bill: yess, your mail came up.
[16:37:21] <derek> I agree that we still need crypto evidence, otherwise we're purely back to an assertion of user identity...  meaning a 'trusted' server can impersonate anyone without "proof".
[16:37:53] <nico> it'd be nice if Java had naming attrs support...
[16:38:12] <nico> derek: there's no more need for crypto evidence here than in the SASL case
[16:38:18] <kaduk@jabber.openafs.org/barnowl> Bill: if I remember correctly, there was a question of whether user=
and a= are the same thing, or subtly different.
[16:38:24] <nico> derek: if this is OK for SASL, it's OK for us
[16:38:28] Steve Olshansky leaves the room
[16:38:51] <derek> I'm not convinced it is okay for SASL, either.  (and in my use cases we're not using SASL)
[16:39:00] <nico> derek: target services get to decide which middleware services they trust
[16:39:08] <nico> derek: again, you'd not be obliged to sue this
[16:39:13] linus joins the room
[16:39:19] <derek> that's the case even with real S4U2Proxy.
[16:39:31] <nico> derek: not really
[16:39:43] <derek> The difference is that with S4U2Proxy the KDC still gets to say which users the service can impersonate.
[16:39:43] <idra> nico, derek is right
[16:39:45] <nico> S4U-unaware apps will see the impersonated cname/crealm
[16:40:13] <nico> derek: with this approach the service must have policy, and that policy can say "the KDC must also approve"
[16:40:15] <idra> nico: that's a feature, not an issue ;-)
[16:40:26] <derek> ==idra
[16:40:27] <nico> idra: I don't understand what you're saying
[16:40:50] <nico> in our scheme the KDC gets to contribute policy; do you agree or disagree?
[16:40:51] <idra> nico, you are obsessed with "fail safe" is seem, but I and derek see the current behavior as a feature
[16:40:51] <derek> It's a feature that an existing app sees S4U2Proxy the same as a TGS
[16:41:14] <nico> idra: NO, we're obsessed with the difficulty of expressing the policy we want at the KDCs
[16:41:20] <derek> nico: in your scheme the KDC *may* get to contribute policy...  Versus *MUST* contribute policy.
[16:41:32] <nico> derek: that's also true in general in Kerberos
[16:41:36] <idra> nico, as I said before the only thing I am not in favor is that the evidence ticket is optional, the rest is basically a matter fo preference
[16:41:38] <nico> see transited path policy
[16:41:53] <nico> idra: so your services can require evidence
[16:42:05] <nico> what's the problem?  why can't ours have it be optional?
[16:42:07] <derek> nico: which means we now need to re-write every app
[16:42:21] <idra> nico, it should *not* be a service decision whether evidence is required
[16:42:27] <idra> that is a central security policy
[16:42:30] <nico> derek: no, not really (more on this later), and anyways, only if you want to use this
[16:42:33] <idra> not an application security policy IMO
[16:42:38] <derek> IT Admins don't want to let go of that control
[16:42:53] <nico> derek: S4U2Proxy is not getting deprecated (and how could we, it's not an Internet Proposed Standard)
[16:42:56] <derek> (at least in our customer experience)
[16:43:07] <nico> idra: it absolutely should be a service decision
[16:43:09] <idra> nico, I think we need to bring this on the list now
[16:43:12] <nico> same as with SASL
[16:43:40] <idra> nico, our customers want it to be controlled centrally, it's a clash of expectations and security policies
[16:43:53] <nico> derek: again, if you have policy engine capabilities on your KDCs that do what you want, you'll be OK with S4U2Proxy, otherwise you'll be itching fo rthis instead
[16:44:13] <nico> let's pay attn to the mic
[16:44:22] <ghudson> I feel like we've been back and forth on this on the list before.  (The OAuth vs. SASL authzid issue.)
[16:44:33] <nico> can someone tell me what the disagreement on the mic about SASL was?
[16:44:36] <derek> Bill mills is on the Mic
[16:44:45] <derek> Back to OAuth
[16:45:37] <nico> mic: the I-D authors should describe the semantics of the user= thing in details
[16:45:42] <nico> s/details/detail
[16:46:26] <ghudson> I have to wonder if it's even possible to meaningfully map an authorization protocol (OAuth) onto an authentication protocol (SASL).
[16:46:40] <nico> mic: bill: you need to describe the semantics of what you're proposing, and you cannot break SASL's authzid semantics, within those constraints you have a lot of freedom
[16:47:21] <nico> ghudson: well, the application will have to be OAuth aware, it's like a GSS app that expects naming attributes
[16:47:47] <nico> ahhh
[16:48:13] <nico> mic: in the Google case, what component adds the hint?  the client app?
[16:49:03] <nico> mic: :)
[16:49:37] <derek> nico: I don't know how to relay that..
[16:49:47] <nico> mic: but does my MUA need to know about this?
[16:49:54] <nico> derek: stand and smile?
[16:51:19] <nico> we sure had energy here today
[16:51:21] <nico> ...
[16:51:35] <kaduk@jabber.openafs.org/barnowl> As Stephen says, for some things.
[16:52:52] <derek> We are 2 minutes over, but clearly still talking..
[16:53:15] Steve Olshansky joins the room
[16:53:35] <derek> Thank you everyone!
[16:53:37] linus leaves the room
[16:53:39] Zash leaves the room
[16:53:49] <idra> thank you
[16:53:50] ghudson leaves the room
[16:53:53] tlyu@mit.edu leaves the room
[16:53:58] idra leaves the room: offline
[16:54:03] satoru.kanno@jabber.org leaves the room
[16:55:08] jimsch1 leaves the room
[16:55:21] <nico> viktor and whoever should chat closer to the mic
[16:55:23] <nico> ;)
[16:55:30] <nico> so I can hear
[16:55:38] <kaduk@jabber.openafs.org/barnowl> They should get kicked out real soon, actually ;)
[16:55:45] m&m leaves the room
[16:55:50] <nico> oh, BTW, we didn't get to talk about the TLS resumption and tls-unique problem
[16:55:53] cw leaves the room
[16:56:03] <nico> kaduk: hmmm, that's no good
[16:56:13] <nico> oh well
[16:56:15] <kaduk@jabber.openafs.org/barnowl> since eppext has the room
[16:56:55] <nico> well, there's 4 more minutes anyways
[16:57:06] Steve Olshansky leaves the room
[16:58:58] sftcd leaves the room
[16:59:20] Karen O'Donoghue joins the room
[16:59:31] scottcantor@jabber.org leaves the room
[17:00:45] Karen O'Donoghue leaves the room
[17:02:29] derek leaves the room
[17:03:56] derek joins the room
[17:04:02] <derek> nico: that was me talking with Viktor
[17:04:18] <derek> We just have very different use cases
[17:04:37] satoru.kanno@jabber.org joins the room
[17:05:13] m&m joins the room
[17:05:20] m.jenkins.364706 leaves the room: Disconnected: Replaced by new connection
[17:05:21] m.jenkins.364706 joins the room
[17:05:26] m&m leaves the room
[17:05:30] m&m joins the room
[17:05:38] derek leaves the room
[17:05:43] m.jenkins.364706 leaves the room
[17:06:04] m&m leaves the room
[17:16:07] wmills_92105 leaves the room
[17:16:14] nico leaves the room
[17:43:07] kaduk@jabber.openafs.org/barnowl leaves the room
[18:11:33] satoru.kanno@jabber.org leaves the room
Powered by ejabberd Powered by Erlang Valid XHTML 1.0 Transitional Valid CSS!