Chair: Larry Zhu and Jeffrey Hutzelman Scribe: Shawn Emery AD: Tim Polk IETF 75 Stockholm, Sweden City Conference Centre 7/31/09 - 09:00 - 11:30 am We had technical discussions on FAST ID and IA-Kerb. Shoichi made a presentation on the proposed DHCPv6 Kerberos option. Tom gave us an update on the Kerberos consortium activities related to SHA1 hash usage and proposals. Overall we have 7 documents either ready or close to be ready. The Kerberos OTP document generated considerable amount of discussions in the list during the past 3 months. The discussions are constructive and the chair believes this document is converging and currently in good shape, though a working group second last call is deemed necessary due to significant changes made or to be made as the result of these discussions. Here is the meeting note: Agenda Bashing None. Document Status Starttls: No open issues, Jeff is shepherd, waiting for chair write-up Love: Anyone other than Simon that has implemented this? Simon: None that he knows of. Tom: MIT has implemented FAST, has no intentions to implement FAST. Tom: Why? Because of complexity of TLS and infrastructure requirements. love: was the channel binding issue resolved in the starttls document simon: we can add cb separately, no push to put in core document simon: is there a strong need for cb? client verf kdc cert, no need for cb. simon: client does not verf kdc cert, cb does not help. krb over tcp is safe. jeff: nico is not here, reserve discussion until present. love: I don't think cb are required. Data model: Jeff is sheperd Waiting for Leif to send a new revision. leif: Will get a new version shortly after the IETF. leif: no new comments after 04, 05 should be straight forward to proceed waiting on chair IA=krb: one last in back in November Made change based on comments today. tkt ext: is document ready? Love: will submit a new revision based on Sam's comments. DHCP Option: jeff is sheperd soichi: dhc wg chair, wanted a summary of the krb wg. no comments jeff: at present there are not charter items. had discuss with chairs, had no place in the dhc wg. Preauth framework new rev at 13 sam had lc comments waiting for PROTO write-up Anonymity: jeff wasn't clear on what else to be done on this draft. tim: new wglc is needed due to significant changes. had wglc, may not need another wglc, jeff will investigate. tim: new wglc were needed were indicated on his notes ball is in our court love: has wglc comments Naming-constraints: waiting anonymous draft should move forward when anon is ready no open issues pkinit hash agilities: love: document is ready, tim had ready. Waiting for larry's write-up gss-cb-hash agility: No problems, write-up in progress cross realm problem: no issue tim: blocking items have been cleared, next version goes to the IETF referrals; no new progress, will work with Ken to make more progress otp support: last minute issues raised have consensus to close all issues except one: krb flag, if 0 bit is reserved or not, first bit is zero change take PIN protocol out of cored document put in separate document pre-auth framework: if the type of armor is unknown, what is the error returned by the kdc new error returned by the kdc jeff: wg lc ended at June, not sure all comments have been addressed new name in crypt challenge remove test vector out of current draft that describes DES love: what does client verification of kdc reply mean? client machine does not trust the user any identity can verify its own identity on its own sam has addressed concerns in text, w/no arguments love: problem with statement "we dont need to worry about future mechanisms" what we have is pw and pkinit, trying to generalize to framework love: framework does include thoughts on how pkinit works within this love: would like id to be more clear is framework and that of specific mechanisms we don't handle pkinit in this doc is from the fact that pkinit is not worth the effort, not justified love: not concerned about pkinit vs fast love: can't nest pkinit within fast and vice-versa, can't hide my identity to the network tom: we have not done much work with how pkinit works within the preauth framework. framework may not be generic love: no attempt to describe how pkinit works with the framework most of the issues are implementation issues, practical issues no reason to believe that fast can be encapsulated in pkinit love: should separate which parts should be generic jeff: there should be plenty of time to work on issues, bring to list love: tried to comment on last meeting, tried to raise issue several times before. sending to list may not be affective. split document in two parts: generic description and mechanism specific love: need to be clear which parts are not specific to just password mechanisms paul: documentation issue. could split in two. tried to use password to describe the framework paul: split into appendix love: separate in document or two separate documents is ok armor for tgs: like generic mech to use non-TGT armor should allow for generic ticket armor implementation very problematic and has security issues consensus is to remove explicit TGS armor resolution: require strengthenReply key in case of TGS, client does not know if KDC is compatible separate protocol to discover if kdc supports fast adding neg portion in draft, based from referral draft TGS case x-realm support for fast is more difficult suppose to updated in next revision of referrals DHCPv6 options soichi sakane presents jeff: we decided to adopt as wg item, not the dhc-wg more than one implementer would be helpful in deciding the usefulness of options jeff: not in charter yet, my fault 3 sub options define realm kdc information client principal name already have dns to provide kdc information issues should be resolved service type: transport medium, e.g. sctp, http (heimdal) simon: #'s for tcp, udp, sctp, http, needs one more for tls soichi: needed for boot strapping for client leif: re: tls, negotiation problem simon: similar to http leif: need to know this before you start to talk to kdc soichi: 3495 can provide a timer for how long a ticket is valid soichi: dhcpv6 cannot provide ipv4 addresses, don't know how to address issue love: should provide addresses for ipv4 tom: how many of these devices do not speak ipv4? tom: how many of these devices are supported by ipv6 kdc servers? paul: transition from 100% v4 to a mixture of both. paul: fine to provide only v6 address. paul: unsafe to handle out both address types. love: support for both addresses. Give them the options to do so. paul: you are allowed to send it, but you are telling them which direction. jeff: standardize dhcpv6 option should not preclude ipv4 addresses. tom: now agrees w/Love, paul in this regards. paul: don't recommend one address of the other. soichi: no clear definition of default realm love: default realm is a broken concept, designated realm would be a better description jeff: whatever you call it, you are supposed to say what it is used for charter update: jeff: suggest we do this right now tim: agree on which problem we are trying to solve on dhcpv6 options larry: what do i need to do to update charter? tim: one or two sentences on what is being addressed and update milestones on when this will be in wglc. jeff: write that sentence right now. Define a new DHCPv6 option to carry a set of configuration information of the Kerberos protocol. Milestones: Feb 2010 WGLC hash algorithms: tom: asked about impl something else besides sha1. Problem w/NIST statement about sha1. tom: heard hmac(sha1) is safe for now. tim: fine with hmac and kdf tom: cts presents problems with crypto hardware, not approved by NIST tim: we could provide a statement online for your customers larry: will be helpful if we had something to have something on this specific with Kerberos tim: think that this is a fine idea jeff: NIST should post a statement, but should not post an I-D on this paul: CTS is a real issue, a relience on DNSSEC keeps on coming up. paul: when DNSSEC gets signed, will have sha1, not sha2 paul: be mindful that dependencies of Kerberos is using sha1, viz DNSSEC tim: no way to migrate to sha256 by dec 2010 in root zones jeff: no cts statement from nist is not so much of a problem compared to peformance problem in crypto accl jeff: there is more of a problem with the use of insecure DNS jeff: no much interest with hmac with sha2, but should consider ccm/gcm larry: no need to wait with sha3, since interest is in ccm/gcm larry: we should start work now then, regardless of the sha1 fallacy paul: only working group talking about sha3, sha3 is not on a tight schedule paul: should throw out any consideration of sha3 tom: not really considering sha3 tom: more concerned about what will the next hmac look like IA-Kerb larry: wglc last November, one lc comment larry: comment: adding text in the sec consd section larry: lessons learned from the implementation larry: 01 encoding is bad, adopted from SPNEGO, everything else does not larry: does not work out very well, not consistent with 4121 larry: require the entire sec context to include token and token id larry: 01 does not specify how to populate the iakerb response larry: added text to clarify, editorial larry: no support for clients that have not joined the domain larry: the client does not know how to do referrals larry: iakerb server can work with any kdc larry: use the kdc server to ask for referrals larry: client can start with one realm, in the case of no join there is no starting realm. jeff: no ok to start with arbitrary realm love: they know there name and pw, just not the realm larry: the client doesn't need to know to trust this information from the server love: we ask the server first then the kdc jeff: the server's realm is part of the server's name larry: is just a starting point in order to bootstrap the client realm larry: use the server realm to hint to the client's realm tom: issue with the insecurity of the server realm to the client which realm to authenticate to love: using a round trip to discover the client's realm is acceptable to me jeff: we need to be careful about wording and not use the term server realm larry: the server only needs to tell the client what realm, not necessarily the realm of the server tom: text should include that the realm is only a hint Open Mic love: I want to one-page draft. Want to move DES to historical. larry: is there value in doing so? tim: should be deprecating DES, if not done already, should be done. love: fast still referencing des, should not spend cycles worrying about it larry: yanked DES test vector of preauth framework jeff: no longer widely deployed should be correlate to publish of draft jeff: should add to charter for DES to become historical tim: let write the sentence Decprecate DES Kerberos ciphers, move them to "historical" milestone: November 2010 WGLC jeff: poll the room support: concensus no support: none no opinion: none Session over.