IETF 89 - kitten Working Group Minutes ====================================== Location: IETF 89, London, England, (Hilton London Metropole) Room: Park Suite Time: 2014-03-06 1520-1650 Co-Chairs: Sam Hartman Shawn Emery Josh Howlett (DNA) Secretary: Simon Josefsson Scribe: Matt Miller Jabber Channeler: Derek Atkins Jabber Log: http://www.ietf.org/jabber/logs/kitten/2014-03-06.html Audio Recording: http://ietf89streaming.dnsalias.net/ietf/ietf895.m3u Action Items ============ * Chairs: will help Tom Yu schedule the krb registries work. * Sam Hartman, Nico Williams, Hannes T: review sasl-saml-ec draft. * Sam: edit pkinit-alg-agility draft. * Chairs: issue WGLC for iakerb draft. * Tom Yu: take cammac issues to the list, before chairs can make consensus calls. * Chairs: setup conference call to resolve remaining sasl-oauth issues. * Michael Peck: Update AES-SHA2 draft to support CTS and 3961/3962 confounder. * Sam: ask mailing list for feedback on 6112bis. * Shawn: update 4402 to bis and ask feedback on the mailing list. * Weijung Wang: Submit bis draft for 5653. Conference Session ================== # Active WG items (15 min) - IANA-reg draft-ietf-kitten-gssapi-extensions-iana Waiting for Alexey and Josh to create initial registry. - KRB-IANA-reg draft-ietf-kitten-kerberos-iana-registries ACTIONS: * Chairs will help Tom Yu schedule the registries work. Tom Yu: The Registries are not yet ready, but some portions might be soon. Ben Kaduk: Still volunteering to review - SASL-SAML-EC draft-ietf-kitten-sasl-saml-ec Reviewers before WGLC: * Sam Hartman * Nico Williams * Hannes T Sam Hartman: I will review the document, and if it's fine I will issue WGLC How many have read it? (two hands, including chairs) Scott Cantor: Thank you Nico Williams: I read it a while ago, but will review again. Hannes volunteers to review - PKINIT-alg draft-ietf-krb-wg-pkinit-alg-agility Volunteers for edit draft? (none) Sam Hartman: I am happy to work on it. The updates are non-controversial. - IAKERB draft-ietf-kitten-iakerb ACTION: * Chairs to issue WGLC Jim Schaad: I also believe it is ready for WGLC. - CAMMAC draft-ietf-krb-wg-cammac ACTIONS: * Take issues to list before making any consensus calls TY: We can take it to the list # GS2 Updates (15 min) SH: How many implementations of GS2 are there? I am aware of one, maybe two. It would be interesting to know if we have two independent interoperable implementations. # Update to OAuth (15 min) ACTIONS: * The chairs will help setup a conference call between the knowledgeable parties. Agenda for the conferene call: * Discuss the semantics of user= * Get enough SASL and OAuth people in the same place for adequate review * What does it mean to remove GS2: - remove all GS2 stuff - make it GS2 compatible, and it ignore it - make it GS2 compatible forever Hannes: The updates since last time have been to remove the GS2 aspects and to limit the specification to OAUTH bearer and OAUTH 1.0. It might be better to go ahead with this. SH: I want to understand what this ser= contains? Does anyone understand both OAuth and SASL really well that can explain it? HT: You want to map the different identifiers (SASL specific to OAuth). There are actually three different identifiers (SASL, OAuth, Application), this is one way to help map them together. SH: What Bill described on the list is not the same as a= in GS2. User= and a= do different things. I would feel more comfortable if someone that understands both to write some text that explains user= and authorization and explains how they are different. SH: The broader question is: is it reasonable to have an identity protection without channel bindings. Shawn Emery: I don't think he talks about that. I think that deserves discussion. SH: It sounds like the user= thing does not conflict with the authzid. But I want to understand it better first. Nico: 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 SH: They can't be in the GS2 headers thing. I think it's fine for the conceptual OAuth2 GSSAPI mechanism to carry arbitrary things, and to have a GS2 header and not conflict. Nico: to answer Sam's question about whether it'd be OK to carry an unprotected authzid, see also Simon's GS2-bis I-D Chairs: We will re-read the document. SH: Is there anyone that is willing to help resolve this? Nico: Sam, yoiu just said that this stuff would have to be inside the OAuth token, which was what I'd said SH: Oauth token has a different meaning to them, and it might not be the same as our view. HT: The OAuth token is created by the authorization server, and the client cannot do anything with it. Nico: I agree to help resolve this Nico: right, sure, we're using our terminology here HT: We can try to arrange a conferene call between everyone. Nico: I'm saying the user= thing is either superfluous or it's the authzid necessarily. Scott Cantor: I agree. SH: I cannot be included by a security standpoint. But it might need help to determine something is valid. In Bill's case, it sounded like an authorization. It might not be surpuflous, but it does not have security concerns. Nico: SASL doesn't speak of carrying anything other than the authz-id. Nico: anything like an authenticated ID comes from the internals of the mechanism. SH: I understand why you would not want one, but I think having it increases interop. Nico: 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. # AES-SHA2 (15 min) Consensus was for cts cipher block mode and 3961/3962 confounder support. ACTIONS: Michael Peck should make updates to the draft accordingly. # RFC 6112 and RFC 4402 Issues (5 min) ACTIONS: * Document Editor will request other feedback, then ask chair for WGLC SH: I have questions for the WG. We have two implementations that turned out to be interoperable because of this change. 1) Do we want to publish this as an Internet Standard? I think we've got enough implementation experience. Stephen Ferrel: We've done some of these, and I don't remember what the rules are, but if we want to try it we can. SH: I have asked Pete rules-lawyer for me. During that dicsussion, we might have found the IESG might not have been consistent with the BCPs. Nico: how can this be a standard without making RFC4120 a standard? SH: You can have downrefs. What Pete and I are discussing is how to do that. SH: 2) Are there any other changes we want to make while it is open? None from the room :: RFC 4402 Issues :: ACTIONS: * Will ask WG via ML, then possibly WGLC Questions for WG: * Does anyone start their counter at 1? (none) * Do implmenetations stop at or Ben Kaduk: you stop when you have enough bits, it doesn't matter n or n-1, really. SH: The starting point impacts the answer, so it's a big interoperability deal. SE: Do we know what Heimdal does? SH: I think we need to do a survey of implementations to find out how much of a rathole this is. Greg Hudson: Heimdal starts at zero, like MIT. Ben Kaduk: 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. SH: We need to find out what Microsoft does; they don't have an API for me to determine this. This could be another situation where we got lucky. Volunteers to update RFC4402? (none) # Per-user host-based services and S4U2Proxy Improvements (10 min) :: PUHBS :: Derek Atkins: How does this work with reverse DNS hostname resolution? Viktor D: We turn it off. We turned it off for other reasons. SH: The RFC says "MUST NOT do the reverse host resolution", and you MUST NOT for very good security reasons. Simo Sorce: you chould never depend on reverse resolution anyway; it is always broken in most depoyments anyway. SH: You should know that the port sometimes shows up in MS deployments. VD: Yes, and we have big workaround when the GSS id includes the port. SH: It would be good to note this, and recommend or anti-recommend it. VD: We anti-recommend. SH: And you should get MS involved in the BCP. Whatever your deployment's provisioning is what it is. But you'll need to get buy-in for the alternatives. VD: I'm not sure about them using outside of MS-SQL. SH: IE with SPENGO. VD: I don't believe they do that anymore. SH: My understanding is that recent versions still embed the port. We need to look into what is going on there. VD: They don't call them domain-based services. But across realms it breaks. What MS worked with me was to allow ":" in the hostname. SH: That is a standards issue, and that would be a fun discussion to have. I'm not trying to make the problem more complicated, but if you don't get consensus you'll only be able to say this is what you've done. But if you get consensus then you can say what others should do. VD: I haven't seen this day-to-day of port numbers showting up. SH: We should get them involved. Danial Kahn Gilmore: I want to understand the CNAME thing. You don't want someone to spoof DNS VD: I don't want to, but it's how it works right now. Nico: well, when CNAMEs cross boundaries the idea is that the KDC must know this too and issue a referral SH: What 4120 says is to not fully resolve the CNAME, but to have a principal for the CNAME itself. VD: I'm hoping DNSSEC will protect us. SH: Unfortunately RFC 4120 says MUST NOT resolve and MUST NOT forward. VD: Here we got to some principal id. Simco Sorce: why should you key the CNAME ? (already answered) Nico: you must key the cname because you're not supposed to chase the CNAME during name canon VD: In MS shops you have to do it the MS way, but in other shops you need it to cross implmementations. SH: It's really great to see someone interested in this stuff and doing this. :: S4U2 :: Volunteers to review this draft? * Derek Atkins SH: If the application is a SASL application, why isn't the authzid not good enough? You might need a mapping... VD: Semantically we are conveying the authentication data and allow separate transport of authorization data. "Hi, I'm Viktor, but I'm pretending to be Sam so that I can see how it behaves for him (troubleshooting a bug, etc)". Practically speaking, we could say this doesn't need to be as feature-full as SASL. I don't have any preconceived notions on the exact semantics. This is a raw proposal, so there's lots of space here. We're trying to change the way you proxy to be more at the application layer. It could look like SASL but we would be locking out going up the layers. SH: I would bring up the layering question, but this is really cool stuff. SS: 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 VD: What we are seeing is that it doesn't map to the world I live in. Nico: Sam, because existing apps tend to know how to deal with principal names (well, ours anyways) DA: I want IT control to determine who can impersonate who for what services, and this seems to bypass all that. VD: We are backing this with a policy system. We are trying to prevent modifying all the KDCs in order to bypass deployment obstacles. The KDCs are blind to the impersonations and we think the applications should make their own judgement and know that it is going on. SS: for our scenarios KDC control is fundamental DA: I think there are deployment scenarios where both happen. VD: That model can fit here, but the name attributes is always the middle servers, and it makes the decisions. The only thing we are really fundamentally changing are the KDCs that see the middle boxes as the authenticator. This is a feature to us, and the feature of transit loops. I personally think proxies should be banished, but that doesn't fit our customer. Nico: there's no proposal to obsolete S4U2Proxy (which isn't even an Internet Proposed Standard) VD: Here we are looking for a lot of input from the WG to see what should be done. This is really new, and weren't planning to talk about it right away. SS: I think my main problem is the lack of evidence ticket, anything else is just a deployment prefernce. Nico: the principle here is to follow the existing precedent for transited policy Nico: that precedent is: the KDC can contribute its policy, but the target service has the final say SS: when there 2 competing mechanism you have half apps using one and half using the other, this is an interoperability problem SC: the benefit is this mechanism surfaces the information indifferent to GSS mech VD: It doesn't solve all the problems of a proxy, but solves the one's that impact us the best. The idea is this is an app-layer thing for it to be aware of all the impersonations and do the right thing. SS: not really if you have 2 hops VD: Not quite. Our intention is to make this fully recursive. SS: you see only the last application if I read it right TY: 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 SS: only if you have crypto evidence, which you say is optional # RFC 5653 Update (5 min) Any objections to the changes? (none) SE: Propose that it be an update to the RFC # Open mic (5 min) Bill Mills: Did the question on the new round of GS2 not needing mutual auth come up? SH: What question? BM: There was a request on the list to put the GS2 stuff back into SASL-OAuth. SH: There is a proposed change on the list. My understanding is that the protocol hasn't changed between -10 and -12. BM: The proposal on the list to remove the GS2 header. SH: Ah, I thought it was to remove the reference to GS2 but leave in the header. BM: I think it's fine if you can provide it but ignore it. SH: The reason it is important is because one side might be using GS2 and one side might not. But they need to interoperate. SE: Are there concerns about backward-compatibility? SH: If we ever plan to do this with GS2, we want compatibility with what already exists. BM: One way is to have this as an ignored kv-pair. SH: That completely misses the point. There are things in the header that have security concerns (authzid). BM: What we had before was to ignore the stuff in the GS2 header. That you must derive the SASL identifiers separately. SH: We need someone who knows SASL to review this. What you just did would break SASL. It is not up to an authorization service to determine the identity. The earlier outcome was for a conference call, and it sounds like this needs to be on the agenda. BM: Then it sounds like the user= should be good enough. SH: What you are saying on the Mailing list, it sounds more like a hint for authorization. SH: The user= sounds like something that can be handled in the mechanism layer and not in the GS2 header. BM: This came up numerous times. I would like someone to say clearly what it is we need. I would not want to go through another round of updates to get back to where we are now. SH: I understand the frustration, but we need people to do the review work. Nico: the I-D authors should describe the semantics of the user= thing in detail. 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. BM: It was intended to be a hint, because the identity being asserted is derived from a token. SH: Do some auth servers need it? BM: Google needs it as a routing hint. SH: But its something that if you don't specify it will break? BM: It will break. SH: Then we need to document it, or we won't have interoperability. BM: The spec already mandates it, and defines what the kv-pair is for. Nico: in the Google case, what component adds the hint? the client app? SH: Nico is trying to trick you, you should say the client mechanism. BM: Yes (-: SH: What Nico is trying to ask is if the email app needs to have it or the oauth layer. BM: The oauth layer needs it, but the email app probably wants it too. It's more about the app knowing how to communicate with the SASL mechanism. Nico: but does my MUA need to know about this? SH: We need to take this to the conference call. In order to avoid frustration, we need to make sure we get good representation on the all. SF: I want to thank you guys for the chairs' service. We need to decide what to do going forward. BM: Are you saying the GS2 and SASL mechanisms will interoperate? [ to be continued on the ML ]