IETF 88 - kitten Working Group Minutes ====================================== Location: Vancouver, BC, Canada - (Hyatt Regency Vancouver) Room: Plaza A Time: Thursday, 7 November 2013, 15:20 - 16:50 EST Co-Chairs: Sam Hartman Shawn Emery Josh Howlett (DNA) Secretary: Simon Josefsson Scribe: Matt Miller Jabber Scribe: Rhys Smith Jabber Log: http://www.ietf.org/jabber/logs/kitten/2013-11-07.html http://www.ietf.org/jabber/logs/kitten/2013-11-08.html Audio Recording: http://www.ietf.org/audio/ietf88/ietf88-plazaa-20131107-1300-pm3.mp3 (2:20) Action Items ============ Josh Howlett: Alexey Melnikov and Josh to work on initial registry subset for draft-ietf-kitten-gssapi-extensions-iana. Sam Hartman: Update the draft-ietf-krb-wg-pkinit-alg-agility document and Jim Schaad to validate the ASN.1. Jim Schaad: Publish update to draft-ietf-kitten-iakerb soon. Chairs: Will ask the AD to take RFC 6112 errata approval to IESG. Rhys Smith, Robin Wilton, and Ben Kaduk: Research registry numbers for draft-ietf-kitten-kerberos-iana-registries. Shawn Emery: Update GS2 specification to allow mechanisms that do not support mutual authentication. Alexey Melnikov volunteered to review. Chairs: Have draft-ietf-kitten-aes-cts-hmac-sha2 authors contact active participants and find out what's acceptable/unacceptable to each party. draft-ietf-kitten-sasl-oauth Authors: Remove -PLUS related text in current draft and resubmit to the WG for review. Conference Session ================== PARTICIPANT KEY: * JS - Jim Schaad * SC - Scott Cantor (REMOTE) * SE - Shawn Emery * SH - Sam Hartman * TY - Tom Yu (REMOTE) * BK - Ben Kaduk (REMOTE) * NW - Nico Williams (REMOTE) * MP - Michael Peck (REMOTE) Administrivia ------------- No bashing of the agenda. Active WG items (15 min) ------------------------ 1) IANA-reg draft-ietf-kitten-gssapi-extensions-iana [ ACTION :: Alexey and Josh to work on initial registry subset ] 2) SASL-SAML-EC draft-ietf-kitten-sasl-saml-ec * SC - Ready for WGLC, but waiting on abfab * SH - Is it dependent on EAP-naming? * SC - Yes * SH - EAP-naming is in AUTH48, so we can do the WGLC soon 3) PKINIT-alg draft-ietf-krb-wg-pkinit-alg-agility * SH - I propose for me to go and make the changes, then recuse myself as chair for this. This does mean I cannot update the ASN.1 pieces, but can do the minor changes. * JS - I can do the ASN.1 validation [ ACTION :: SH to update document, JS to validate ASN.1 ] 4) IAKERB draft-ietf-kitten-iakerb * JS - I missed the comments, but I need to publish and get review for MIT interop. We did decide on a method for doing that interop, but need MIT people to look at it. [ ACTION :: JS to publish update soon ] 5) CAMMAC draft-ietf-krb-wg-cammac * TY - "other-verifiers" issue is to prevent it from being empty, not to limit its length * SH - It makes sense that others should not * Chairs - Any comments on CAMMAC? (in room or on-line) * BK - Or we cannot put it in anything at all * SH - In most situations, it would be wrong to not put in anything at all, or they would reject the ticket. * TY - I sent summary to the list today. 6) RFC 6112 Update * SH - I don't think people want to see a new 6112. Does anyone object to a new RFC. * TY - Given the resistance to errata, I support 6112bis approach. * SH - One question is that if we do the new RFC, and think this is stable enough, we might be able to publish as IS instaed of PS. Do we want to do that? It would be odd for this to be the first IS, but if it's mature enough we should. Is it mature enough? * TY - Maybe also include ECC support? * SH - This does not include any algorithms. ECC support is informational, but I don't think there's anything specific to ECC. * SH - Is there consensus in the room to approve the errata? I have seen support on the list, but it is posible for the IESG to not approve it. * SH - There is a specific erratum, the question is if that erratum should be moved to accepted from pending. * SH - The sense in the room that we have consensus for approving the erratum, but the AD thinks there is no support in the IESG, because it seems like a technical change. However, it seems more like an editorial mistake. * JS - If yours the only implementation with this error, or does everyone do it. * SH - It was discovered during interop testing, and the proposed change was to violate the spec and do whatever MIT's implementation does. It seems clear that we need a -bis. It would be nice for the errata to be approved, but in the long run there will be a -bis document. [ ACTION :: Will ask the AD to take errata approval to IESG ] 7) KRB-reg draft-ietf-kitten-kerberos-iana-registries * BK - I can do some research on some numbers * TY - Sent some mail just recently, but need voluteers. * SH - Any volunteers? (Robin volunteered) * Rhys Smith - I would be willing to do it if you can give me some help [ NOTE :: Robin Wilton and Rhys volunteered, but need some help ] GS2 Updates (15 min) -------------------- Discuss updates to the SASL-GS2 specification to remove the requirement for mechanisms that do not provide mututal authentication. * SE - I volunteer to work on it, but will recuse myself for this document. [ ACTION :: SE volunteering to update, and Alexey Melnikov volunteering to review ] Update to OAuth (15 min) ------------------------ Discuss updates to OAuth draft which excludes GS2 text. Consensus was to progress OAuth to RFC as just a SASL mechanism. * NW - I don't see how no mutual auth and still support -PLUS variants * SH - The point of channel binding for SASL is that you are trying to detect MITM attacks, and you don't get that without mutual authentication. But without mutual auth, the binding is one-sided, and I'm not sure that's a valid model. If we have that model, it should not be a -PLUS variant. * NW - I agree with Sam. * SE - Anyone need channel bindings, but cannot do mutual auth? (none stated) * Klaas Wierenga - I will just wait calmly for SASL-OAuth to be approved, and will rip the SASL-SAML version apart. * SE - I think we're doing this pre-emptively. * SE - Noting that no objections to remove -PLUS from Bill Mills, and no comments from Hanness. AES-[CTS|CBC]-SHA2 (15 min) --------------------------- Determine if the WG can reach consensus on which mode will be standarized for draft-ietf-kitten-aes-cts-hmac-sha2. * BK - note the mail I sent right before we started, mentioning KDF and such. * AN - Are you still considering CBC? It's unclear right now. * SH - I think we had a situation where we had consensus with something we are unhappy with. If something new came along to move us to a happy state, it would be good. But without that, I don't know that we can change. * AN - I want to continue objecting to using CBC, because we have implementation problems. * SH - There have been discussions on the list about what implementation options are possible. But you need to be careful about that from an IETF perspective. We can't have a consensus call on whether a specific mechanism is acceptable to a specific implementer. It is worthwhile input for an implementer to state viability, but we cannot make an implementer change. If the implementer decides they can implement it is fine, but but they get to make their own decision about whether they can implement something or not. * AN - I am concerned about the impact to existing implementations. * SH - I noted that there were some people asking for MS to change their implementation on the list. * SH - As I understand the issue today, you rarely get padding with SSPI, especially with RC4. * NW - I'd be OK with an explicit IV CBC mode, but I don't think we'll reach consensus for that * NW - I'm opposed to using counter modes without updating RFCs 3961 and 4120 to provide for additional key-reuse prevention inputs in the cases of keys other than sub-session keys * MP - We posted both CTS and CBC versions of the draft. Happy to go with either. Microsoft is obviously an important implementer * NW - the simplest way forward is to adopt confounded CTS and call it a day * MP - I'm also concerned that counter mode can't be used safely * BK - a specific application that would have trouble with padding, that is * SH - With my chair hat on, I'm really uncomfortable with the "do you have a specific application?", and that's getting too close to the line. * SH - I understand why GCM and CCM can't work for us. What's not clear to me is why CTR can't work for us. I would like to see an argument for how long you can use the key if you have a 128-bit counter and pick a random starting point, and where you run into collisions. It's not obvious to me if you can't split up the counter. * BK - Are there concrete examples or is it purely theoretically. * NW - I'm utterly uncomfortable with that for long-term keys * SH - You ought to be able to do the analysis. I think I am comfortable saying you can use it for keys of 2^64 blocks. But I'd like to understand how much worse than that a counter is. * TY - I think we need to think hard about the risk tradeoffs of counter modes. they might actually be OK for Kerberos long-term keys given what information collisions leak. * TY - the only really sensitive thing encrypted in a long-term Kerberos key is a session key * NW - our implementations would have to start implementing heuristics for when to change passwords/keys, renew/refresh tickets. I find that to be too much. Keep in mind too clients that have low entropy to start. * SH - If no one but me wants counter mode, then it's not worth doing. * MP - Can we attempt to decide between the CTS and CBC proposals? Counter mode could be a separate additional proposal. * SH - I don't think so becaue there has been much interest in a confounded mode. * TY - I didn't realize I was an author (-: * SH - I think it's better for the authors to talk to implementers than to have polls. * NW - consensus call proposal: is the room/list opposed to confounded CTS? * NW - consensus proposal 2: is the room/list opposed to explicit IV CTS? * NW - consensus proposal 3: is the room/list opposed to explicit IV CBC? * SH - I would rather people talk to each other. I don't want to proxy two people talking to each other. * SE - There are definitely good things here, so we want to see it moved forward. * NW - That's where I was going; I agree with going to the list or having a conf call [ ACTION :: Authors to contact active participants and find out what's acceptable/unacceptable to each party ] New Drafts (5 min) ------------------ Draft to be adopted by the WG draft-williams-kitten-generic-naming-attributes. QUESTION: How many people have read draft-williams-kitten-krb5-pkcross? (couple of hands) NW - I'm not implementing at this time, so I am happy to return to it later. I personally think that a non-shared password cross-realm keying protocol is *badly* needed. TY - interested in solving the PKCROSS problem; not sure i like the current proposal due to implementation complexity and deployability concerns, but i'm willing to be convinced SE - We won't make a call for adoption now, but request those that have offered to review to do so. SE - Regarding draft-williams-kitten-krb5-pkcross, there's been a request to adopt this. I support adopting it. SH - I don't support it. The rationale for adopting channel-bound was fixing something we did. But adopting this item would require a recharter. NW - so recharter if we must; but, really, we ought to have the charter include fixing errors in RFCs under our purview. SF - If you conclude that it needs a recharter, I won't object. But it would help if you know about how long it will take. If it will take a long time, I'd rather not adopt it, but if it's quick we can take it. BK - "improvements to the GSS-API" is in the charter auth-indicator draft QUESTION:: How many have read the draft? (a couple of hands) * SH - We need more reviews. gss-loop draft QUESTION:: How many have read the draft? (Shawn only) * BK - do we want to poll about standards vs informational? [for gss-loop or auth-indicator] * TY - authentication-indicator is one way to get LOA indication into authdata, and i think it's in charter, or authdata in general is. * SH - I agree it would be easier to recharter, but it would require people to read the document. * SE - It's premature to call for adoption, so please everyone review this draft and comment. Open mic (5 min) ---------------- None.