IETF 105 EMU Agenda Wednesday Jul-24-2019 1330-15:30 -------------------------------- 1. Administrivia (5 Min) 2. WG Documents (20 Min) - draft-ietf-emu-rfc5448bis-05.txt - draft-ietf-emu-eap-tls13-05 - draft-dekok-emu-eap-session-id - draft-arkko-eap-aka-pfs - draft-ms-emu-eaptlscert 3. RFC 7170 (TEAP) Erata (25 min) - https://www.rfc-editor.org/errata_search.php?rfc=7170 4. TLS-based EAP types and TLS 1.3 (5 min) - https://tools.ietf.org/html/draft-dekok-emu-tls-eap-types-00 5. Recharter Discussion (30 min) 6. EAP-Noob (15 min) - https://tools.ietf.org/html/draft-aura-eap-noob-06 7. TEAP-BRSKI (10 min) - https://tools.ietf.org/html/draft-lear-eap-teap-brski-03 8. ACME Integrations (10 min) - https://tools.ietf.org/html/draft-friel-acme-integrations-01 Minutes ------- Recharting discussion? changes to agenda? None. EAP-TLS 1.3 John Mattsson presented remotely Changes and next steps removed text on other TLS-based EAP methods comments after WG last call by Jouni Malinen use of empty TLS record is not supported by OpenSSL, whereas TLS 1.3 allows it. OpenSSL also does not support early application data without early_data extension need decisions on these comments Mohit at the mic: implementation is more complex if there are multiple options it seems better to just send one byte of zeroes and that's it John: Question, should we document OpenSSL's requirement to send NewSessionTicket, otherwise OpenSSL won't send early data to an unauthenticated client. mic: Jim Schaad. Doesn't seem like a good idea, because the server may not want a newSessionTicket. The server can still send a message saying we're done after it's authenticated, and it should work. John: the spec says otherwise right now Jim: the server can send that message after client authentication. It's just the first encrypted data message from the server to the client. John: To allow that we will need to rewrite the spec. It's not clear how that interacts with the EAP state machine. Jim: it should match it fine. Just send that message instead of the newsessionticket John: Sounds good Joe: Will clarify it on the list John: It will introduce an additional round trip, but it seems OK. Will send summary to the list. Joe: If there's no contention, we can move forward with this Large certificates draft changed text to address discussion on the list. need WG adoption and reviews. All WG comments have been addressed Joe: Will call for adoption immediately after the meeting EAP Session ID - Mohit: We should adopt and WGLC as soon as possible. Need to change the title because it implies it is for all EAP methods Joe; Will start adoption call after meeting Joe: another draft waiting for adption, EAP-AKA PFS, but concerns about IPR issues. Consensus that the document is needed, and should move forward. Target is informational. Proposal is to adopt it as WG item. AD (Roman): not objecting, but didn't want to object. Did we call out IPR issues? A: yes RFC 5448bis - Jari - Gone through WG LC. Some feedback. New version was published, with some minor changes. - added table of attributes, can / may appear in packet. Didn't exist in 5448, did exist in 4187. Added to be clear on what's needed and what's not next steps IESG no comments, no objections to marking it as ready for IESG Daniel: document seems ready Eliot : who has reviewed the document? 5 people. + 1 jabber Jari: many other people from 3GPP and Ericsson reviewing it TEAP Errata - Jouni Malinen filed errata against TEAP RFC. Will walk through errata asking for opinions Joe: proposed to accept the function signature for TLS-PFS errata. Asking for more responses. Will tell Roman who can do the next steps errata for Authority-ID is optional, proposal is to accept it. No comments from the room. Eliot: why was it a MUST in the first place? Joe: Good question, we don't know. Perhaps because EAP-FAST has a similar construct and may have bee marked mandatory there. We will continue the discussion on the list. Mohit: is there text on what implementations should do when the TLVs aren't there? Eliot: in the middle of doing the implementation for TEAP. Let's take time for implementations to see before we move ahead. Errata (5767) for authentication method text. Proposal is to adopt it. But may hold off until the implementors come back Roman: if we're going to be waiting, we can just batch the, and set a date for when we go forward if we don't hear back from the implementors Joe: yes, Jouni's implementation is waiting Errata 5768 - compound MAC is fixed to 20 bytes SHA1 is no longer used, we need to decide what to do. Simple fix is to truncate. It may be better to have variable length. Will work with implementors to work through the issue. Roman: timing Q again. Maybe wait until next IETF in Singapore Elliot: Should have implementation by end of summer as a default timeout point on answers. Errata 5770 - Joe: Needs to get clarification as it is incomplete. Errata 5775 - Joe - Value missing if not a key generating meethod. Need to decide on whata to use in that case. Follow on question is do we need to do a bis version of TEAP. But this can wait until after all of these errata issues are decided. Elliot: The Brski work was modifying this and if the document is opened then could do it in this document rather than as some extenions. Alan: Next document fixes TEAP for 1.3 does not deal with 1.2 right now, but could roll that into this as well or push to a different location. TLS 1.3 - Alan FAST and TEAP have more difficult key deriviation - punting on TEAP would make things easier for this document. Elliot: No personal opinon - will go back to team Recharter Discussion Mohit: Proposed text is a superset of current text in terms of current work items Roman: How many poeple have read it? - 2 (+1 in jabber) Alan: What do we do about people who are violating current EAP standards and put things out which are not reviewed? This is not part of the charter but may want a discussion. Roman: What is the public act being proposed Alan: If IETF is in change control for EAP, what can we do for external issues. Roman: Not chartering of a new issue Bernard: No EAP Police to call and have them arrested. If security thing then would not get blessing from NIST Alan: Some 3GPP work has migrated out of there and is continuing. Do we have a charter item to work with people to get review on these things. Mohit: Expert review to get an EAP method #. Perhaps provide Alan: Not new stuff - changes to existing EAP methods. Current expection of IETF review is not happening, but not sure what can be done. Mohit: Can do some contact with known changes. Roman: Don't need to change charter to talk to people, only for new formal work (i.e. document). Mohit: Comments on the new text is welcome. Does it cover everthing that needs to be done? Roman: Suggest changing the text to be more in line with what the old charter was laid out in. Mohit: Old items were fixing things, but this is for new work. Roman: Wants to know who is interested in doing the work (author and implement): Joe: OOB work - ~ 6 people raises hand. Write code? Alan for sure Eliot: where is the TEAP work covered? A: entire second paragraph Eliot: seems some inconsistency between first and second paragraphs. Mohit: trying to capture current ideas, but updates are welcome Eliot: it's clear that TEAP work is needed. Recent conversation is that they're not even sure if they want an outer TLS connection. We need to have that dialogue here. Mohit: text doesn't require TEAP Eliot: We may want to separate out third line text into deliverables text ? (CableLabs): seems to already be covered Eliot: general text is good enough to go forward Roman: still confirm on list Joe: limited use EAP authentiction methods which can be used to create long term credentials - 6 reviewers - 4 implementors EAP-NOOB - Tuomas: presenting slides working for 3 years on this, implementations in hostap and wpa_supplicant, modeling and verification, peer implementation in Contiki Roman: Q: slide on SAAG presentation has wrong date; should be March 2019 Joe: questions? None, moving on TEAP-BRSKI - Eliot - quick update. Added Security Considerations had to combine join registrar and EAP server to satisfy BRSKI requirements that signatures match and are bound all the way thru need implementation and development testing. Finding ambiguities in TEAP. doing wpa_supplicant and server implementation may need 802.11 or WiFi alliance integration to deal with the 2K SSID (BSS) problem. Hunting through them is time-consuming and expensive Joe: No comments? Dan: Could this voucher that TEAP-BRSKI uses be considered an OOB mechanism? Eliot: Partly. this ties into the Anima architecture. Could go to manufacturer for voucher, largely in-band. Or, been given a voucher (somehow) and placed it into a join registrar. From that point, it can authenticate without a cloud transaction. Or sales integration that happens, may hand you voucher at the time of the sale, which then goes into the AAA infrastucture. But these use-cases shouldn't change the bits on the wire ACME TEAP integration - Given same presentation in Acme and Anima. Using cloud as back-end for certs when doing enrollment over TEAP strong interest in doing EST over BRSKI work Eliot: Thanks for this. A lot of small enterprises don't want to run a CA. Ability to link to public CA will be useful. I think what you're asking for the TEAP work is that do we need an error 202 code for the draft we put together? A: yes. Where is resource consumption? What if the CA is unavailable? WHat if someone is holding state? How does state expire? Dan: how do you envision that these certificates get named? In the CSR? A: It's an open issue. How does the device know what FQDN to put in? Joe: it's interesting to get a "come back later response. But it largely means no network. The person gets a token to come back and call later. A: could work with session resumption? ACME supports "call me back later" Joe: ACME would maintain the state. But no network connectivity until that point Mohit: anything that happens beyond the TEAP server is not a concern for EMU. could use ACME? Does ACME do client certs? ACME seems mostly to be domain validation and not client certs? A: use-cases are for both client and cert getting certificates Mohit: Is this the WG for it? Or is ACME? A: work may be required here in order to do this. Is the mechanism by which the station knows the FQDN? Mohit: it's not the station. Michael: It involves changes to the TEAP state machine in order to deal with this. ACME already deals with this. Mohit: maybe we can look into it. It should not be the device that says "issue me the cert". It's the server. The server should enforce this. A: client generates the CSR and the server interacts with the CA Mohit: server would still enforce it when it sees the CSR Joe: Server enforces policy, but client generates the request. Joe: more questions? None? Agenda is done. Other topics? Bernard: working off-line to get Alan contacts for PEAP and TLS 1.3. That's the only comment. Roman: pet topic sharing in all WGs. Can we put a list of implementations relative to drafts, so that it's easily accessible? Will help with interop testing, and helps to advance the drafts. Mohit: RFC 7942 says that drafts should include a section on implementation status, but a Wiki is good too Dan: Other business - EAP-PWD' new draft is available. Please have a look Bernard: Q on interop tests for TLS 1.3 and EAP