Interim Meeting - kitten Working Group Minutes ============================================== Location: WebEX: https://ietf.webex.com/ietf/j.php?ED=179545787&UID=1381218722&PW=NYTQ2YTA5MjY4&RT=MiM0 Audio Conference: 1-650-479-3208 Access code:640 049 742 Time: Monday, 6 May 2013, 08:00 - 10:00 PDT Co-Chairs: Sam Hartman (attended) Shawn Emery (attended) Josh Howlett Secretary: Simon Josefsson Security Area Director: Stephen Farrell Scribes: Ben Kaduk Audio Recording: TBD Attendees --------- Ben Kaduk Scott Cantor Klass Wierenga Nico Williams Greg Hudson Tom Yu Jim Schaad Zhanna Tsikov Action Items ============ Chairs: Poll WG of following items: 1. In regards to draft-ietf-kitten-sasl-oauth, RFC 6616, and RFC 6595; do we allow for GS2 mechanisms that don't provide mutual authentication? This would entail changing the GS2 specification (RFC 5801) to relax this constraint. 2. Do we allow the IAKERB draft (draft-ietf-kitten-iakerb) to pull in the finished message text from the PKU2U draft (draft-zhu-pku2u)? Subsequently, if the PKU2U draft is progressed, it will make a normative reference to the IAKERB draft. 3. In regards to draft-williams-kitten-channel-bound-flag; are you in favor of using the NULL context solution for the channel bound indicator as opposed to a new set credential API? Conference Session ================== Mutual Authention SASL Mechanisms --------------------------------- Shawn Emery: Thanks for joining. first thing is mutal auth/sasl that Jeff Hutzleman and nico brought up main goal here is to find out how to proceed; the three mechs openid, saml, and oauth break the GS2 requirement of having mutual authentication. The current text in the oauth draft/openid+saml rfcs is hand-waving that mutual auth is done outside the mech via, e.g., tls, but then it returns it, which contradicts the GS2 text that "mutual authentication is required for the mechanism". There's a couple of solutions; one is to change the GS2 spec to not require mutual auth; another is to remove the GS2 feature for the sasl mechanisms by updating the oath mech draft, openid and saml sasl mech rfcs. Sam Hartman: specify as pure sasl mechanisms, without ??? Nico Williams: in particular drop the dash-plus sam: if you keep as GSS mechanisms, the dash-plus comes via GS2 unless we update GS2 so that sometimes it doesn' t have the dash-plus nico: how do we do that? sam: if you don't want to update GS2, you have to... nico: we're going to ahve to because we want mechs without mutual sam: no consensus nico: I'm asserting that we do sam: you probably favor option 1, update gs2, as opposed to option 2 nico: oh, I mixed up what we're discussing sam: could say, big mistake for gs2 mechs to try and reuse technology; we're going to decouple these and go fix them later ???: sam, how is this different from just taking all the gss stuff out of ... sam: that's what it is shawn: another option that might be interesting is to bring back stackable pseudomechanisms, and then have a composite mechanism akin to ... openid or oauth mechanism. Have that be a requirement for mechanims, stacking TLS and the underlying auth mech. sam: you don't want to do that. the reason I'm pretty sure you don't want to do that is that one of the desires behind the oauth and saml mechs is to make them easy for sasl apps to implement without knowledge of gss, ... with a minimal amount of code. Changing the requirements so that you can't use a stock tls library as you normally would would require a lot of code. nico: agree it's not likely to happen; not worth bothering given that. Scott Cantor: the requirement for mutual auth is directly related to channel binding stuff in GS2, is that right? [yes] sam: I'd like to understnad that better. To decide, want to know (1) what applications want to use these mechs as gss mechs? (2) why does GS2 have these requirements nico: easier to start with (2). We have new mech, browser-id based one, which is public-key based. You can do channel binding without mutual auth, and it means something, more than for other mechs like oauth, and yet it's still a little squisy. There is a reason we want mutual and channel binding at the same time. Are we discussing this later or now? cantor: my mech does not mandate mutual (but supports), but it's designed to plug into gs2, so I may need to update language depending on what happens here today. sam: saml-ec I can't come to a conclusion on 1vs2 (drop vs update). If there are other questions people have, we can add to the list, but we need to discuss questinos soon. In my mind, "why does gs2 have this requirement" sounds like a good first one. shawn: have mech author online, ask him? Was there demand sam: don't want to go that way Do we think, from a gs2 standpoint, that we will see this in the future. ???: do want to say, when started out, had not thought about test mechanisms; I brought it to kitten, a suggestion was made, and it made sense. Don't see any demand yet, but could be in the future. cantor: gss isn't even a question, as ssh is key target (not sasl) nico: okay, thta was useful sam: nico, you have most knowledge of gs2. Can you discuss why we need... nico: when we wrote rfc5256 on channel binding, had only nebulous idea of what original authors wanted, and so did the original authors in 2743. When Sam and I worked on this, we saw that in order to do CB, the whole purpose was to eliminate MITM; we needed some properties to decide that we had succeeded. Someone has to check CBs same on both sides, and the other side has to believe that it has happened. There's a sidebar here for whether the initiator needs any confirmatino that the acceptor has [done so?]. If we do mutual, and mech can confirm that CB is same or different on both ends, then mutual is sufficient. GS2 threw out some of the complexity of GS1 by using CB; provide integ protection via GS2 header and channel binding, if the mech supports, is great, but didn't think about at the time. If we had thought about it, might have done mixed token like GS1, and that would probably have failed. So we're stuck with only CB as a way to provide integrity protection for the stuf fon top. sam: want to know, who cares about integ protection. Working through... we send bits from client to server; information about whether CB was used, and info about authorization identity. That's all that is sent with integ protection [nico confirms] shawn: there are extensions nico: we made it extensible, but didn't provide extensions. sam: apology to all for taking so long, want to make sure understanding correctly. ???: point out: no integ from gs2 itself; presumption that no cb and you're sunk or cb and will check later sam: one problem with gs2 discovered in this discussion, is that gs2 always assumes that all mehs support cb, and provides integ protection for cb. This is false, and gs2 has a problem, quite serious, if used with a gss mech that doesn't do cb. cantor: emergent property of mech, not built into gs2 itself. sam: gs2 has a different idea of how gssapi works than reality. to be secure, gs2 should only be used with mechs that provide integ protection of their channel bindings. shawn: what if integ done not for target mech, but that cb can be verified? sam: I don't understand. shawn: right now, if TLS has been used, then that is used to provide the integrity checking as opposed to the mech itself. sam: wrong because of cut/paste attacks. Maybe. Actually,we hadn't considered that. nico: means that application has to use tls, too. Feature of mech that must be advertised to application developers. [example of how application developer thinks] end up in situation where not needing to care about CB. sam: not sure... nico: end up always using TLS, widest possible trust anchors, so that will always interoperate. That means possible MITM. The only way to interop, but then you're scurewed. tlyu: in practice, non-web apps using TLS, how to verify server cert? cantor: lucky if do it at all; builtins of platform libraries. wouldn't rathole on this issue. That it breaks the gss abstraction makes it an edge case or rule it out entirely nico: the lack of security in webserver pki is a motivating afctor for CB. If it turns out that we can't live without tls, and we can't do anything about improving the security of that pki, then we wrap it up and go home. we say we screwed up. sam: gs2 requires tls. nico: but not the pki. cantor: my mech letes me federate the server pki. sam: still trying to understand question. HAve information, authorization identity and cb flag. Server cares about that, because the server wants to make sure that the CB flag hasn't been cleared by an attacker, and the server cares that the authz identity is the same that the client sends. nico: oh. Can we backtrack and discuss authz id and then CB flag? sam: only if better understand security reqs. nico: if we knew whether the initiator tried to use CB but the attacker cleared the flag, then we don't care, because we know that the initiator tried to use CB. Sam: didn't parse. nico: gss acceptor received token, also GS2 app. Do not see CB flag in the gs2 header. If, inside token, there was CB information, and mech could tell us (instead of ignoring it) [sam: never pass null CB for gs2] then we fail. [sam: that's how we detect failure today; we fail there] cantor: problem is, if clear flag, and server treats that as indicating to not check, then this falls apart if don't use plus version of mechniasm. Posit a secneario where CB is not required, then attacker can MITM and clear it. nico: problem we had was this: we needed a particular case, we need to not even try CB on the client. We know a priori that this mech can't do what we awnt; we're not relying on it. We need to actually know to rely on the tls server pki. We need to know that we don't get to do dash-plus with this mech. a priori, we need ot know that a mech like, say, oauth, can't do dash-plus. That's roughly the soultion I was looking for. cantor: what are you expecting outcome of security negotiation to be. Can certainly use such mechs with gs2, if you understand that there's a whole set of guarantees that you won't have. I wouldn't have thout=ght that was news. nico: it is news...going back to sasl applicaiton developer cantor: my presumtipon is that people deploying such applications that do understand security impliciations but just don't care. Is the concern that something is reported to init or acceptor that is inaccurate, or is the issue that what's reported is right, just some poeple don't like answer. nico: no, what I want is, I'm looking at how to use sasl framework, an actual api that exists now, and I want to know that I am giving security to the user that asked for it. If I pick oauth mech with bad trust anchors, then I lose. cantor: your version of "lose" is what vendors are pushing as next generation of security nico: if I can have mitm that goes undetected, then I lose. I don't see any... cantor: I agree with you, but that's not consistent with the rest of the world. What's the issue with gs2 -- if it's that things are accurately reported but that the security guarantees are not particularly strong... nico: I'm not saying you don't get to use oauth; I want either app to know upfront with sasl which mechs to use if the user cares about mitm avoidance, or alternately, when it's done, have a boolean to indicate whether there might be a mitm. The latter has the problem that the user can't ever get it to use a mech for which the user has credentials, that might work better. I'm putting this in APIs ... sasl has no guarantee for these kind of demands. GSS has them, SASL does not. The diea with dash-plus was to provide this sort of guarantee. If we take it out, and the user can see what could have been used, then they can see what could have been. But most people won't care. So I want the first thing. cantor: just trying to udnerstand actual functionally broken parts of the rfcs. Don't want to just make a avlue judgement. We coudl say we would rather not have had these things as wg mechs post facto. I'm not seeing yet a statement that gs2 is misreporting. nico: it absolutely is. It's the dash-plus cantor: gs2 can claim that cb was done when it wasn't? nico: gs2 can claim that cb was possible when it wasn't. nothing can confirm that something was wrong. what went wrong is the ability to have a mitm. That's it for me, I'm done with that. cantor: isn't that a property of any mech that doesn't to cb and mutual? nico: no, I want to know a priori whether this is something I ahve to worry about, and then deal with it by, e.g., dash-plus. But if dash-plus is a bad idea, we need an api somewhere that tells us what the mechanism really does, or indicate what actually happened. But with the caveate that we might always fail. cantor: really the gap is there isn't a way to report (particularly to initiator) what actually happened. nico: yes. But I could go either way on this one. Want user to be able to succeed when it's possible. If we keep putting up warnings, the user is going to click through. We want to avoid that. cantor: deployment issue? nico: no. We might want to scale to the size of the web. How can we know? deployment is on the client side problem. Client might want to operate against some sites where do/don't care about mitm. Would have to manually adjust set of mechs usable for various connections. gets back to the first option that I gave. So I think we need both. Again, this is all at the API elvel for sasl, not the protocol. Whatever we do here, the spec for sasl or for gs2, that it's going to upset the sasl purists. And I'm okay with that. shawn: from the gssapi standpoint, what would mutual auth really mean at that point? nico: we didn't finish taht discussion, we went to something else. [on direction to take discussion] cantor: core discussion is "is gs2 broken" sam: if you're trying for a consensus call, you're driving me against the discussion; I'm against consus about anything for this topic. the questino of "what are the security requrimenets" is really important to me, but we're off so far into solution space that I can't follow what is being said well enough to even have an opinion. nico: not trying to discuss solutions, but rather what properties I want for the user. sam: I don't even understand the securty properties of what we have today. nico: what we want is more important than what we have, though cantor: will be difficult to achieve consensus about security properties at that level of detail. nico: the internet threat model assumes active attackers tlyu: in practice people ignore parts of the internet threat model nico: what is the threat model here? how can we have a discussion about anything without nowing what we want for security properties of the whole thing? I don't care about gss or gs2, I care about what we get at the end of the day. cantor: sliding set of requirements; important nis to report accurately to applications so that people can make choices and write code. don't think there will be an agreed baseline for securiyt properties nico: if we can't care about secure interop, then I don't think we can even have this discssion. I'll throw in the towel; we can document gs2's lack of security, but that's all I want to do know. If someone else has a better suggestion, that's fine, I'd love to hear it. shawn: I'm trying to tie in your proposal for qualificaiton of what mutual authentication entails. nico: we're getting into details...how can we achieve a different result by starting discussino from botton up instead of top down. At the end of the day, it's what we get out. cantor: we have people writing mechs, writing specs. We can't force those opinions onto everyone else. sam: interrupt with process issue. Shawn, s 6.5.2 rfc 2026 file appeal about process being used to move forward in that meeting. A point where two participants have said that they are throwing in towl and walking away at some point. SEveral people have critical opinions who aren't here. I don't know what the right answer is, but this process in this meeting right now isn't moving forward, and even if it did, I don't think any consensus would be good. We wouldn't have confidence in it. nico: reschedule with more people? sam: we tried to schedule. I don't know what to do here; we don't need to walk away frmo this meeting ... the current discussion. We both feel that the issues important to us aren't being addressed, and something needs to change about the process to move forward. nico: how does that appeal get addressed. Can we reach consensus of no consensus. sam: you were talking about something else; I withdraw my statement. you threw in towel on issue, not process. nico: could confirm on list we failed to get consensus on actual technical isssues. We cannot reach consensus for entire wg today because missing participants. Might be others, lurkers, who have other opininosn, who might help on mailing list. I'm not trying to hijack the process into saying were done, we have no consensus. Am saying we have a conflict that we don't know how to resolve. Without resolustion to that conflict, we cannot find consensus. Leave someone in the rough, or everyone comes around sam: to me, I'm not even convinced that conflict is important to how I would decide on the technial issues. nico: new opinion, please explain. sam: we are thinking about the problem in entirely different ways, and I'm being left out of the discussion. I want to start from where we are today and I can't wrap my mind around starting from where we want to be and workin back. I haven't even gotten to a point where we need to understand the issue. nico: I have a problem going the other way around. To me it's clear that we want a systemic property of some sort. You don't want to discuss it that way at all sam: Do at some point want to look at systemtic stuff, but also we have an existing system to day and I'd like to understand it as an incremental thing. Not sure that all applications are going to have the same systemic problems. For exmaple, there are sasl mechanisms today that don't fit into this model. sasl plain is a well-defined mech. nico: doesn't have a dash-plus. dash-plus was supposed to give us a systemic property that we want, that the user would say "I don't want a non-dash-plus" sam: you want a systemic property from dash-plus. If there's a dash-plus mech, then you don't need to nico :depend on the server pki sam: is scott disagreeing with you about that? cantor: no. I'm just trying to understand where we are, so that we can understand what to change. nico: what does dash-plus mean. Chris Newman's suggestion; he's not on the call. sam: what is disagreement betweeni scott and nico? nico: maybe isn't one and we are confused cantor: reacting to staemente "if possible for dash-plus and not to exist in the world, then we can unilaterally decree that no one uses non" nico: want user to knwo what level of security they got cantor: is there a limitation with the spec that prevents that from happening? (not applications) nico: there are mechs that don't verify CB cantor: that's my earlier point; people have decided that those mechs have value; we can't pull them sam: scott, your question is hard. Nico and I will give you two completely different answers to this. My answer is, there's a spec bug. GS2 is missing today a paragraph that it intended to have, "only use this mech with mechs that actually do CB integrity" if you have that paragraph, you get that today. With that pp, it's quite clear that we mispublished the existing rfcs. Another answer I could give you is that there's al imitation in the spec, that basically that you have dash-plus mechs that don't verify cb integrity, and that makes it very difficult for the application to understnad what it's getting. There are multiple ways to interpret the facts, to see what problems exist today. cantor: example? sam: oauth, simple samle, openid. cantor: they don't try to verify cb. How could they be dash-plus? sam: gs2 does not allow you to have a non-dash-plus mechanism. The question of do you advertise dash-pluus is a factor fo does the *application* udnerstand CB, not the mech. nico: server side ... ... sam: pelase undestand problem before jumping to solutions, I can't handle much yet. cantor: so we're saying that gs2 framework presumes that any mech that foloows the framework is inherently providing both the non-cb and the plus-cb variant and that they both do the right thing. IF a plus is chosne, you actually get cb. nico: better to say that gs2 assumes that gss mechs provide cb. cantor: trynig to write a mech, you don't think in those terms. but I understand better what's oging on now. sam: could give a defintiion from both sides of the layer that are provably identical. Nico's is great for thinking as a gs2 implementor. nico: what I said earlier that upset you may have done so because I said it in terms of implementation details. In actual english, we want sasl sam: the phrase "what we want" makes me upset nico: the problem is, sasl/gs2 allows you to advertise dash-plus for mechs where dash-plus does not give you want we intended for it to mean. sam: two ways to do it: change gs2 or eliminamte mechs nico: or change what dash-plus means. sam: think no one is proposing that. option 1 change gs2 option 2 decouple mechs that can't do it right nico: do we want consensus on which to choose? sam: still want to understand problem tlyu: possible problem with #1 -- there are several different gradations of not supporting channel bindings, that applications might want to distinguish among, and we would be doing a great disservice to them if we did not provide them a way to do that. nico: expand? What gradations? tlyu: please be patient. app (either side) wants to know information about what security properties its channel has. sam: want to understand what properties gs2 needs; tlyu: trying to do that; nico: gs2 needs for dash-plus, or period; sam: assuming gs2 works today, want to understand what each side authenticates and why each side eepends on integrity protection, and what you get out when it works today; nico: we could start withi authz id nico: what goes wrong if we don't check authz id sam: mitm could change and change level of privilege granted server could care about information disclosure (e.g., s4u2u-like thing) IN that case, both server and client have availability and integrity interest in protecting the authz identity. nico: doni't disagree, as in practice, people only have one avaliable authz id to them. Sam: in that case, you don't send it. nico: right. attacker can strip, modify, or add it. sam: both server and client potentially have interest in integ of authz id. I'ma sking about that because I want to get around to what mutual buys us. Client gets to know that server verified things. ONly important if the client happens to have an interset in their integrity. If client doesn't care if attacker changed authz identity... nico: why does mutual get you information that the server validated the id? sam: only possible thing I could ... gs2 seems to be making that assumption. I think it's true for all mechs that provide cb and mutual nico: what about kerberos? sam: validate that cb input on init/acceptor are the same. If you have mutual auth, then since authz id is included in cb input, then have confidence that authz id has not been modified. cantor: yes tlyu: ??? sam: this is true for all gss mechs providing cb and mutual, as used by gs2, that we know about. ??? For authz id, the cb input is confirmed byt he server and by the client. cantor: gs2 in general or when a plus mech is used? sam: for this, in general cantor: my ipression is that gs2 is asaying if you don't use plus mech, then there are weaknesses but you are apparently accepting those sam: could accept weakness, or say you only get to use authz id if you have cb and mutual. cantor: not trying to focus on solutionst, but what are we saying about gs2 under what conditions. sam: if without mutual, the server is able to confirm cb, then an attacker cannot modify the authz identity. Without mutual, might not be talking to same server... nico, can you think of a reason we care about mutual for authz identity? nico: no. But mutual means different things in different places. name of server, or talking to same person? In kerberos, you know name of server, the second message is completely irrelevant. sam: second message means that you're actually talking to that entity nico: yeah, but no harm in talking to wrong one if they can't decrypt them. Then you don't care about a mitm. sam: well, session setup is relevant, so many applications for which learning that you don't have a session key at session setup is useful for implementaiton reasons. nico: why do I care if mitm can't change things? tlyu: you're making assuptions about application protocols nico: just because didn't have mitm once, doesn't mean that there won't be one later (who drops packets, etc.) sam: mutual means keytab is correct, detects operational problems. tlyu: I didn't hear anything in your exmaple about what protections the application porotocol was providing for your syslog-type scenario. Cleartext? Auth or integ or confidentialty protection? nico: say conf udp packets to the ip address, but maybe it's the wrong one. the mitm could stop sending my messages to the real server. If I want to make sure that it gets back to the server, I need acks ,but the AP-REP does not buy me anything. Learning the server's name is valuable, but for kerberos you already have it. tlyu: for kerberos it does have additional value, but don't want to gaet bogged down in details right now. nico: but that's what sam wanted? sam: don't think this is valuable either. nico: we're talking about mutual; I said two meanings. Which one do we want? sam: there's a third one. ??? mech verifies server name is as intended, and gss context establishment is guaranteed to fail if the other end is not the intended server name. It's not just good enought that the other end can't decyrpot it, you need to know that they did. Say using gs2-krb5, and krb gets rid of its apreq, cause you say they don't need it. I'm an attacker, want to impersonate the server. You send your token, and it might just go and claim success. Because there's no ap-rep, you're willing to go on with a converstaion with me. nico: yeah, but I'm not really, because I'm encrypting everything. sam: gs2 nico: oh, but this is gs2. Okay. sam: gs2 gets from mutual, and it's not clear that gss gives this, but gs2 wants it. i_s_context will fail lif wrong server, and (2) server confirms that there are channel bindings. tlyu: that makes sense. Also remind people that authentication is not proving an identity or verifying it; authentication is the association of an identity with some other piece of information that is security relevant. For kerberos, the ap-req associates timestamps, servername with a particular cryptographic key. mutual indicates that the server has successfully decrypted and verified the authenticator. sam: aslo important to note that the kerberos gs2 mech also indicates some things with respect to channel bindings. tlyu: right sam: if the cb flag is important because an attacker could set the cb flag and it wasn't integrity protected, then the attacker could impoersonate. could cause server to think that cb was used whtn it was not. Could be not big problem, as server might not care. Attacker could clear cb flags and cause success when there should not be success (i.e., when mitm). Very important that client can confirm server receipt of cb flag. nico: we really want mutual insense of confirming cb. Don't waht it in the sense of mutual, but in thes ense of confirmed cb. ??? nico: want to get into discussion about what it means for acceptor to not have a name but have mutual. sam: can't have dash-plus for that, but not sure. nico: ??? not clear that it's useful either. A lot more useful than nothing at all. that might not apply to gs2 at all because we always want to have a service name. sam: okay, now that I understand the security properties... does everyone on the call who cares think they understand the gs2 properties? [roll call] do we get value out of having gss mechs that don't do cb? I think that's the right way to phrase the question, can we agree on that? cantor: answer seems "yes", as ssh is an application in general sam: we'll get there do you agree that that's the right question? cantor: yeah, because I think you're jumping over the gs2 piece and can work backward to get to the right thing. sam: applications where want to use a gs2 mech that isn't in sasl. ssh is one, but ssh requires evn more, it requires mics from the mech. cantor: not for authentication sam: that's right, if mech doesn't support integ, then it doesn't have to produce a mic. nico: hope that's not so cantor: there's an authenticaiton-only option for using a mech with gss sam: [to nico] see seciton XXX of rfc XXX I think Scott's right. nico: for keyex, if integ is not available then you fail. I'm just reading through. [shawn: process, 20 minutes left; 10 minutes for each item left on agenda.] Sam: based on this, I'd say yes we do want such gss mechs, and that makes me in favor of option 1 (change gs2 to support mechs that don't do mutual and have them not have a dash-plus variant). cantor: don't feel qualified to have opinion on gss mech issue, but was tyring to make it quick by raising ssh issue. shawn: okay, we'll craft options and post to the list, get consensus there. tlyu: I think option 1 needs some pretty substantial security considerations text attached to it if we're gooing to do taht. shawn: yes. sam: maybe. Yeah, possibly. shawn: nico, being one of the original authors, would you be able to update the gs2 spec nico: possibly, yes sam: Simon may have some cycles. He may have an opinion; he said he was going to post something to the list but didn't get around to it. shawn: he was going to comment on our discussion as well. okay, so I think the chairs can go and craft the text for the consensus call to make (obviously after nico, scott, and co-chairs go through and make sure that we accurately construct the text for the call). Channel Bound Proposals ----------------------- shawn: I think we can move on to the channel bound proposals for gss since the list never reached consensus on the two proposals. I forget which one, was it Martin that was suggesting the null context? Or was that you, Nico? nico: that was me. Martin agreed to review it and say something but he never did. Shawn: okay, and the other option was to have a new set_credential_options to indicate channel binding. Was that from you as well, Nico? nico: I made two proposals, [yes] I prefer the empty context. shawn: the problem is that it kind of has a broader scope of changes required now that mechanisms would have to.. nico: sort of: it has a benefit that it aligns more nicely with the java bindings, for example. Whether people see value is a nother story. It has the benefit that it makes future extensiosn along these lines much simpler. For exaple if we run out of flag bits. For met ehre's a lot of value in that. sam: the concern I have, not a strong opinion, am nervious that we're making it harder and harder to create new mechanisms. The amount of crap you have to deal with to create new gss mechs is really alot. nico: standards-track? sam: implementaiton. The amount of code in ??? that isn't mech-specific is quite annoyingi and large. shawn: the tradeoff is between mech developers and application developers sam: no, tradeoff is between architectural purity and ??? developers. nico: I prefer architecturarl purity. Either way, we're adding stuff that mech implementors have to do. I odn't see how one is simpler than the other. sam: for mecheap, I'm much more confident in... both are doable, I'm not objecting, but I think that the null context is likely to add more instability and more bugs and be a little harder to implement. ghudson: other option? nico: mech attribute, new flags... sam: set_cred option nico: I find all of that ugly, it's not just ugly, I feel like we're painting ourselves into a corner, and would much prefer to have an empty context. It makes the gssapi much easier to use from an application perspective. And we might be able to save gss-eap from having to ipmlement this, if we already have a set_cred something for an attribute than the mechglue might be able to have some bits to support that. sam: only if you can count on all the mechglues. We will implement whatever gets standardized; that's not a problem tlyu: nico, I suggest that your proposal of using a null context as a way to simplify the api has sufficient value that you'er selling yourself short by putting into this other proposal, rather than having it stand on its own merits. nico: I'm willing to separate them and have two rfcs. sam: with chair hat, please don't. nico: also willing to have one rfc. Comment about sam's point about mechglues: no standard api between mechglues and mechanisms. Don't think we want to consider the ease of integrating with existing mechglue; I think that's out of scope sam: I don't, it's an implementation issue that epopel have to face. nico: say have three different mechglue iplementations, need ifdefs and such, I'm fine with it. sam: I'm not nico: I would like to not be fine with that, but there is no standard interface, but until there is, I don't think we can have your desires or mine (as mech or other ipmlementor), we can't... ghudson: agree with sam that the situation for mech developers is bad, but there aren't many of them. There are lots of application developers. So loading context flags into cred options forces those application developers to acquire creds and set options, which is a significant change. Once the null context is in, it's a change, but it cuts out a lot of subsequent stuff. If they had to do creds, then more stuff changes. sam: whoa, didn't think that null context was going to change api for init_sec_context/etc. async isn't on agenda, right? nico: no, it's not. Buf if you want it, you'll want null context anyway. ghudson: maybe Iw as confused, I guess you didn't specify a variant that offered an init_sec_context variant. nico: I didn't in this document. ghutdsno: I think that applications which don't currently get creds would find it difficult to do so in order to set a context flag. nico: I agree, and also say that the beauty is useful for the application as well. shawn: consensus, let's take to list kaduk: and argue about which bits to put in first document nico: third item on agenda? IAKERB ------ shawn: iakerb ghudson: extra bad news, another difference which I think is superficial, which has to do with framing. shawn: first q is do we want to adopt a pku2u draft or include text from it for the iakerb draft. Arguments for pku2u draft is that there are a couple of implementations already kaduk: are people using them? shawn: would require recharter schaad: implmenetaiton of that or of icap (?) I thought otherwise. sam: mit ships iakerb or something close. microsoft and apple ship pku2u. I think apple also ships iakerb. nico: why can't we ship both? what's the q again? ghudson: goal is finish iakerb; problem is the pku2u reference. Can adopt or cut/paste. nico: I think we should adopt pku2u sam: or finish pku2u as individual submission that's the trakc it was on; it had gone through enough review. big question is whether there's enough editor cycles to actually get it done. nico clarifies: should finish pku2u, not necessarily adopt. what text is needed? ghudsoN: the finishend extension. Earlier versions had its own, butpku2u was developed and they decided to reference it. it's a checksum over the conversation. the bigger issue is that when we implemented it we didn't realize that there was a newer version of the draft, and there are some superficial diffs that prevent interop but they use the same mech oid. shawn: also conficts for keys and id numbers from pku2u and iakerb drafts. schaad: if pku2u goes forward you have a real problem. It's using the same extension numbers that mit iakerb is using ghudson: no pku2u finisedh uses type 2 and key usage 41 mit uses extension type 1 and usage 42 draft can go forward as-is, but do iakerb acceptros have to support both also framing issue, we implemented only for first context tokens, but the new one says all tokens. Acceptors could support both, just as for the finished extension. shawn: greg, could you post to list? ghudson: yes shawn: enough information to make consensus call amongst ourselves sam: do we have someone to move pku2u forward schaad: could hold pen on it, but don't have knowledge to know if doing right or wrong. sam: I think we need microsoft to commit to looking at what we're doing and seeing that what we're doing is compatible with what they ship. would they follow the effort enough to interop nico: also concern about how to ??? services. Whole discussion we had in the context of browserid. sam: pku2u does have a solution to that which was agreed on the skim mailing list nico: but might not work in practice sam: enterprise cas nico: yes, enterprise CAs will work. Add an options, existing implementaitons will interop Does that make sense? sam: sure, we can have that discussion, but it makes sense. shawn: Jim ihas agreed to authro sam: consensus: agree to move pku2u forward if microsoft agrees to stay involved in the effort. ghudson: any reason for finisehd to be in pku2u not iakerb? Make iakerb define it (and go first) and pku2u reference iakerb. Requires editorial work on pku2u but I think it sounds like more would be needed anyway. kaduk: jim asked for help pulling bits into iakerb on-list and got no reply. anyone here? sam: hard to move forward on pku2u until Jeff Hutzleman gives state dump. [...] ghudson: I tihnk want finished extension in iakerb. shawn: consensus here for that? [pretty much] schaad: it's stuck in ad-hoc, not clear which paragraphs refer to it. tlyu: requires a little care to disentangle, but I don't think it's too difficult. kaduk: also look at old iakerb drafts for finished extension tips ghudson: yes, though obviusly numbers are different. shawn: okay, I think we have rough consensus on that. We can post to list as well. Do we have enough info to make consensus call for key/extension numbers. If goal is to make MIT implemeentation interoperate, it's not just finished extension but also the asn1 encapsulation of the context initiation tokens. shawn: deployments right now using MIT? ghudson: we don't know. In several releases but we don't necessarily have a channel when people start using our stuff. schaad: anyone using apple's stuff? ghudson: even less information there shawn: love was joined in that discussion? schaad: inclination is roll back to mit numbers and see if anyone yells. nico: looking at heimdal right now. ghudson: I don't think they have it; it's the apple-only verison of it. That's what I was looking at. It seems a faithful implementaiton of the current draft. nico: where ghudson: opensource.apple.com shawn: is rolling back viable? ghudson: problem is, if you implemented this, since use same mech oids, if you were apple and wanted to change in a way to become compatible, you'd have to break your own acceptors. That's mMIT's problem with rolling forward is that you'd break your own acceptors. sam: new oid for standrads track ghudson: not interoperable with either one, but is unique not thrilled about a new oid, for proliferation of krb5-related oids. That said, would be nice if it interoperated with at least one of the implementations. sam: krb5 mech authors already have a mechanism for dealing with multiple oids for all osrts of horrible reasons. nico: it does have an iakerb implementation ghudson: I already looked at it; they did not make it interoperable with mit they used the current draft. shawn: options for consensus call on list are new oid for conflicts... sam: both finished extensions? Framing is hard. ghudson: I think for both of these it's possible to make acceptors work with both kinds of initiators. Not sure if it's both directions of packets. sam: other option is option from intiiator saying "i do standards-track" ghudson: Does it apply only when doing an ap-req? sam: that's ugly schaad: probably cleaner to define a new oid (than to do the extension). shawn: let's propose it to the list, everyone needs more time to think about it ghudson: given that we're over time, I think the framing issue may be premature. shawn: maybe you can post your findings to the list first? ghudson: okay shawn: we're overtime and finished with our topics. Open mic, anyone? [nope] thanks for joining; we'll start working on our action items and add stuff to the list for consensus call. end 13:16 edt Open Mic -------- No one came forward. ============ Session Over