Note takers: Max Crone, Mohit Sethi TLS-based EAP types and TLS 1.3 - Alan Alan: Document is ready. TEAP and FAST is here for now Elliot: Will try to help with TEAP Joe: Will wait for reviews TEAP updates and BRSKI - Eliot Eliot: Need an implementation. Doing without code is hazardous. Implementation of PKCS#7 and #10 issues. Russ: CMS obsoletes PKCS#7 Eliot: How to store? DER? Sean: I thought file extensions were defined. Eliot: Tooling isn't up to the job. Might be okay. Request action frame not clear. Server should ask peer/client to fill in the TLV. Have choices. Define a new TLV. Don't bother. We might be wrong. Joe: Need more detailed discussion on the list. Eliot: Did put out on the list. Cisco v Cisco. We would like some comments and thoughts. Oleg posted responses to errata. For IoT we don't have inner method. Ocassionaly server will say renew your certificates. Or RATS attestation. Mohit: Three related issues: teap errata, how to work with tls 1.3, IoT. It might help if all TEAP experts sit down and organize the documents. Tim: TEAP is not just for IoT, so we shouldn't generalize those statements about inner EAP methods Eliot: Right now, there is confusion about *when* there is an inner method, so that is what needs to be cleared up. Comfortable with Alan working on TLS 1.3. Let's do one document, and let Alan's document continue with TEAP in it. Mohit: Slight preference to have TLS 1.3 updates in Eliot's document. Eliot: First look at Oleg's message and verify/reject errata. Joe: Will review the errata resolutions from Oleg Eliot: BRSKI is easy part. Still corner cases with PKCS #10 Jorge Vergara: will also review errata Joe: Need to see if we bump the version Eliot: Not necessary to bump the version. But want to clean things. Will put forward a draft with old TEAP RFC but a lot of things cleaned up. EAP-TLS with PSK authentication - Mohit Mohit: EAP-TLS-PSK needed because EAP-PSK does not provide identity protection and PFS, EAP-Pwd requires a PAKE. Fundamental question: EAP-TLS-everything-other-than-basics v different documents and EAP-types for different credentials. Eliot: TLS 1.3 specifies that credential should be cert or public key. Specified for both? Mohit: Only certificates. Eliot: Adding support for naked public keys would be relatively simple and desirable. Joe: Group should focus on what is going to be important for the EAP use cases, and not necessarily cover everything that is specified. Mohit: Agrees. Better to have something concrete, rather than having many different drafts. Russ: Where does extern-psk with certificates go? rfc8773 support is suggested. Roman: Preference to focus on what the community wants to implement. Mohit: Yes, everything-under-the-sun approach is less desirable. Joe: Agree, implementations should be leading for discussions. EAP-AKA-PFS: Jari: Don't have a whole lot to say. This draft is relatively stable for a while. One issue discussed in IETF 106 to have more than one curve. In this update, added a proposed to fix/extension to this issue of just having one curve. We had previously x25519. Now I have added P-256. This is early proposal. Strawman proposal. It might be that my specification is not complete. Struggling to find reference. Russ: likes addition of p-256. Can forward a reference. Joe: Encourage people to review. WG item. Jari: Solve one way or the other. Russ: Is there an IANA registry. Jari: Yes, 2 entries. Russ: 2 is fine. EAP-NOOB - Tuomas Aura Tuomas: EAP-NOOB is now a working group draft. First a quick overview, later a discussion of future direction. EAP-NOOB provides out-of-band authentication, which is commonly used but not yet specified. Specifies user-assisted OOB auth, and registers devices to AAA, creating a persistent association that is used for fast re authentication. Most communication in-band over EAP, small OOB message. Implementations exist and are being updates. Formal verification has been done. Next steps are: 1. defining second cryptosuite (currently x25519 and sha-256) 2. Testing of cryptosuite updates 3. Renumbering messages Other things needed before WG last call: 1. Reviews on draft (a.o. security) 2. EAP method number from IANA 3. IAB allocated domain name for the NAI (noob.arpa, noob.eap.arpa?) Mohit: Russ and Eduardo would like to see P-256 as a second curve. Reordering of message types makes sense. Can put Tuomas in touch with IANA. Early review of Security Directorate or IoT Directorate, because draft is already quite mature (worked on since 2016). Eliot: Very likely that NOOB will be the first method to need domain name for NAI, therefore expresses preference for "noob.eap.arpa". Mohit: Agree and wait for response of IAB. Eliot: Not asking for zone support, just for hierarchical domain. Roman: Can talk informally to have a quicker response of the IAB. Mohit: Tuomas will talk to IANA and Roman will help with the domain name. EAP extension to allow peer configuration - Sandeep Sandeep: Working on IoT bootstrapping security for consumer IoT devices, including long term credential provisioning. Configuration layer on top of EAP layer. Issues: EAP does not support message fragmentation, Push v Pull model, discovering mechanism, security for configuration, avoidance of unnecessary roundtrips, limit on number of EAP messages Possible approaches are to define new EAP message type for config messages, or new EAP method that uses existing EAP tunneling method for auth, or new mechanism that allows endpoint to indicate that another config protocol shall continue after the EAP session has ended. Eliot: Similar issues led to the path of TEAP. Fragmentation is handled in TLS layer. Regarding push v pull model: worth exploring. Discovering mechanism sort of supported in TEAP. Sandeep: Would like to explore more, including TEAP. Tuomas: Comment on Push v Pull, interpretation of both will lead to different communication patterns and the number of round trips this results in. Mohit: Likes the third approach. Sandeep: Thinking about minimal set of messages that can be used within a single frame. Mohit: suggests to think about which EAP method to use for auth and find out whether it allows to send config data. Eliot: Reason for doing full config in eap: it simplifies additional configuration. Secondly, when you start to do binding, then you have to do that across sessions possibly across devices, which increases complexity. This would also bring complexity to EAP. So consider finding other ways to do this as well. Administrative Mohit: Is a session in July too soon? Joe: No, would be fine. Multiple documents to discuss. Joe: Make sure that everyone signs the blue sheets, preferably with affiliation. See you in July.