EMU - Boromphimarn 1/2 - Monday 16:10-18:10 Jabber Scribe: Jim Schaad Chairs: Joe Salowey, Mohit Sethi Note taker: Mohit Sethi John: Presenting EAP-TLS with TLS 1.3 2 things we decided to change: Session-ID and Empty TLS Record This is the best we can do aligning with RFC 5216 We have figure of basically every error case. We don't have case for client rejecting session. Do we want such a figure? John: Can we do something more about the identity sent in the first message. Should we mandate Anonymous NAI. Jim: That is standard behavior John: Should we then make it MUST in the draft? Jim: Yes John: Should we give guidance or references on how implementations should mitigate attacks on earlier versions of EAP-TLS. Joe: Hesistant to include things about previous version of TLSs. Jari: Struggled with the same thing in EAP-AKA`. If there is a good reference to point to, you could just handle the things that just apply to your protocol. Elliot: If there are attacks against TLS 1.3 that would not be mitigated by advice given in Security Considerations of this document. John:Should we reference the draft in Using TLS in Applications (UTA) working group. Elliot: Add a reference. But don't re-do it. Elliot: Some of the attacks on TLS are browser related. A line or two on non-browser risks would be nice. There is a sort of blanket ask to move to TLS 1.3 without justifying reasons. You are the boy who cried wolf again. Darshak, Jim and Daniel commit to reviewing John: Jouni had implemented an earlier version Joe: Need more reviews and implementations to inter-op with ----------------------------------------------- John: Presenting EAP-TLS with large certificates Need more reviews. Both drafts are on github. You should look there and open issues. ----------------------------------------------- Jari: Presenting RFC5448-bis Things we missed or things that need to be fixed Talk about pervasive monitoring and privacy. Got comments. General status. Now really in sync with 3GPP specifications. Peer-Id and Server-Id is the empty string. Chose to use the empty string. I don't think it is a problem. Many implementations do not use. Joe: Maybe check if ABFAB is using these identities. May not be relevant for your case. Jari: New section 7.2 on discovered vulnerabilities. No reference on fair and balanced attacks. Russ and Mohit to review during WGLC ----------------------------------------------- Jari: Presenting EAP-AKA` PFS Not a working group item but on the charter Taken into account reviews and discussion More detailed and clarified use of negotiation process. Don't wait for everyone to deploy but do not penalize for those who have not yet deployed. Jari: DoS resistance Russ: Don't remember where the MAC check falls and where the MAC key comes from. It would also affect this. Jari: Higher quality keys exported. But MACs use other keys. Russ: MAC is dependent on the base AKA` authentication. Jari: Yes Jari: Need feedback. See this as WG document? We might be able to stick this in and have affect on people's security and protect from organizations that want to spy on us. Some interest from our side and another manufacturer working on chipsets. We might actually get this deployed if we do it. I would love to move forward. Joe: How many read? Hum if you support adoption: Hum in room Hum if you object: None Joe: Will confirm on list ----------------------------------------------- Tuomas Aura: EAP-NOOB Deploying of Wi-Fi appliances Scanning QR codes or dynamic NFC tags. Don't have to do scaning everytime. Different from current EAP methods that require pre-registeration. Elliot: Great work. Can use slides. Can we use EMU wiki Joe: They are not chartered items Dave: Talk to them all. What QR code do you present at all. User is going to pick one. That is great. The peer knows which one it was. Aura: Important that is delivered to the right Qr code. Erik: Is the AAA server authenticated. How? Aura: Yes, there is mutual authentication. Mariko: Do you need new code on the device? Is there requirement for IoT device vendors? Aura: Implementation on device required new code ----------------------------------------------- Elliot Lear: EAP-TEAP-BRSKI Dan: Do you need some NAI decoration for routing to the right AAA server Elliot: We will steal the idea from EAP-NOOB Dan: If TLS is unauthenticated. Why do you need EAP-TEAP. Why don't you just do EAP-BRSKI Brian: Provisional authentication is only on the client. BRSKI assumes that Server has trust anchor. That is the BRSKI model defined. Dan: Don't understand EAP flows. EAP is a lock step protocol. Dan: Overloading TLVs?