Emu Status PagesEAP Method Update (Active WG)
Sec Area: Roman Danyliw, Benjamin Kaduk | 2006-Jan-20 — 2014-Jun-11Chairs:
IETF-104 emu minutes
Session 2019-03-25 0900-1100: Berlin/Brussels - Audio stream - emu chatroom
EMU WG Note Taker: Massimiliano Pala Jabber Scribe: Elliot Lear - Administrative and Agenda Bashing (Chairs, 5 min) Note Well, Note Takers, Jabber Scribes, Agenda Bashing EMU Agenda: -------------- 2. draft-ietf-emu-rfc5448bis Jari Arkko (10 min) - Presented comments and updates post-WGLC - Two reasons for this draft: new technology has been developed and we needed to address some security and other updates - Comments and Questions are mostly related to technical clarification and editorial changes (i.e., hex vs. dec in the document). Two main points were presented - Permanent Identifiers fed to the KDF: SUPI and KDF * You have two different identifiers (SUPI and SUCI), usually the SUPI is not sent over the wire, but in our protocol it is used with the KDF - there is an inconsistency with 3GPP behavior (TS 23.003 Section 2.2A and Draft Section 126.96.36.199). We need to be sure that the format is the same, otherwise keys will not be calculated correctly. Moreover SUPIs can be either IMSIs or free-form NAIs - while the draft represents everything as NAIs. - New underlying attacks against AKA. When we do authentication protocol using some other protocol as a basis, it is our jobs to use those protocols and document when the underlying algorithms needs to be updated. - The impact of the attacks (eprint.iacr.org/2018/1175.pdf) - the specific attach is a replay attack - you can try to authenticate three types of messages: ok, sequence number failure, or crypto failure. By using the sequence number failure the attacker can discover if the replay attack can be achieved by changing some of the challenges. The attack is perceived as impractical in 3GPP and that is the reason why this attack has not been addressed there yet. - Plan to work this week and incorporate this in security considerations Mohit: the attack seems related more to AKA rather than EAP-AKA and uses the mechanism to re-synchronize the sequence numbers. Jari: what solutions will 3GPP provide? I do not know, we can not predict what 3GPP will do, Stephan Santesson: Downgrade attacks. Is there any new material coming to the draft Jari: I think we covered the downgrade attacks and we think we covered all we needed to cover Joe: We will need a new revision 3. draft-ietf-emu-eap-tls13 draft-ms-emu-eaptlscert John Mattsson (30 min) - Two document updates since the last IETF. * Mandated privacy protection of identities * Differentiate between TLS fatal alerts and warning alerts - 04 has some changes following implementation consideration from Alan * Borrows the term privacy-friendly identities from RFC5448bis * Support for Emergency services (EAP-TLS without peer authentication) * Mandatory revocation checking and OCSP stapling * Clarifications on key derivation, use of ‘L’ bit and fragmentation, and security considerations TLS HellopRetryRequest support Key Derivation - other TLS EAP method could use this specifications for key derivation. Extended types support - shall we provide support for other methods? * Early Data. It is clear that EAP-TLS does not have any use of Application Data. Protection of application data Sean - if we do support early data, we need to make sure we say something about it. Mohit - we shall not use application data in EAP-TLS Mohit: some of the TLS libraries support sending the context but other libraries (e.g., WolfSSL) has not implemented - we shall make this a requirement and then force libraries to support it (RFC5705). Eliot: We might want to have extended types somewhere (Alan’s draft) Joe on Protection of application data: We shall focus on this draft - there is no point including all other methods - with respect to early data, since we have no use for it, maybe we can use something stronger than Ignore Jari: I agree with Joe - what about cross method resumption Mohit: On the list there was some discussion, however I would not want to support it Presentation continues: - Further feedback from Jim and Alan about caching information - Save extended information about the protocol layers below EAP - Just cache information from the TLS handshake Mohit: EAP method do not have access to extra information, and therefore currently we do not have channel binding Alan: Realistically EAP is used within another protocol - to certain extend EAP implementations is only aware of EAP while the encapsulating protocol might be aware of these. Maybe if EAP is aware of these extra information, it should use it Mohit: I am in favor for providing the information - I was referring to the fact that not all implementations have access to this information. Alan: Not all implementations provide this data, but I believe that it is important to provide it Roman (AD): Should we have a place to track all these implementations? Joe: we will setup a page to track implementations either on the Wiki or in GitHub Large Certificates and Long Chains handling: draft-ms-emu-eaptlscert-02 - New co-author Sean Turner - New document structure that addresses considerations about the contents of certificates Joe: anybody can commit to review ? Eliot, Max, Anoop and one more person to review and provide comments. Joe: when we have reviews, we can work toward a WG adoption. John: Allowing the use of cached certificates from a non-completed handshake ? Joe: we might want to discuss this on the TLS list and we’ll have to see the amount of required work 4. draft-dekok-emu-eap-session-id draft-dekok-emu-tls-eap-types Alan Dekok (remote) (25 min) - TLS1.3 and TLS-BASED EAP-TYPES - Key derivation has changed - this affects many EAP methods - The simple solution * Update EAP-TLS to include Method-Type in key derivation and update other methods to use the similar key derivation * There is no reason for each method to define their own key derivation * In this document we provide guidelines - The Harder Solution * FAST and TEAM have complex key derivation * Maybe some external review is needed * PEAP is vendor-defined Can we update vendor specs ? Maybe we can use the code from PEAP ? Discussing with Microsoft - Security Considerations * There are many issues related to EAP and TLS * Some are discussed in EAP-TLS - others many need discussing here * Question for the group is: what other considerations should be added Eliot: Am I actually using TEAP correctly in the other draft - I am a bit nervous going too fast on Section 2.2 Alan: We would like to see more implementation for TEAP so that we get this right Joe: Only 2 people - non-authors - have read it, however it is very important that we get this right. Alan: One comment on this document - one reason this came up, during implementation we felt we need to address other methods as well when updating the EAP-TLS. draft-dekok-emu-eap-session-id Presentation: - EAP-Session-ID has not been defined for several methods - Vendor-Specific methods are likely to have the same problem too - We need this for ERP (RFC 6696) and FILS (IEEE 802.11ai) - I do not think there is controversy here and the document should proceed quickly Joe: this seems straightforward and we can progress this very quickly 5. draft-aura-eap-noob Tuomas Aura (15 min) Presentation: - EAP method for bootstrapping devices out-of-the-box without professional administration - we do not assume the device has any identity - Minor changes in -05 and -06. - A bigger change is that we add one round trip to each exchange to deliver the latest PeerId and peer state to the server without updating NAI (to comply with RFC 3648) and better randomization - Continued the work on formal models: mCRL2 model (protocol - messages and state machines) and ProVerif model (cryptographic key exchange and binding/mis-binding) - Misbinding attacks are possible - if the UI is compromised on a device, then the user might be tricked in pairing with another device instead of the compromised one. There are different ways to mitigate that problem: device certificates, asset tracking through organization, etc. The report is available as a research paper and more in SAAG. - Output from the Hackaton might have an impact over the specifications - can we randomize PerrId ? It is not easy because Identifiers update must be synchronized and should not be vulnerable to misuse of fall-back identifier - Other issues on our TODO list - error handling and timeouts and hooks for application layer configuration (URLs) - Recovering from dropped messages is important: dropped last message in bootstrapping can cause failure. Also dropped last message in crypto suite upgrade could cause persistent failure - We would not like to introduce the crypto suite update recovery method to avoid complexity - There seems to be interest - this could be a work item Discussion: Eduardo: From Murcia University, interested in working on this Dan Harkins: what transport did you use ? .1x - isn’t your method vulnerable to MITM attack ? Tuomas: No, the dynamic QR code is the OOB that provides the authentication Mohit: the hash of the keys is sent not over EAP but OOB 6. draft-lear-eap-teap-brski Elliot Lear (15 min) Presentation: - BRSKI Addresses autonomous on boarding of wired devices (requires initial IP configuration) - This draft internalizes protocol into a new AEP method - Changes since Bangkok * Clearer motivations * All the TLVs now clearly defined down the bits * Added IANA considerations * We borrowed the NAI component from EAP-NOOB - One Issue: What if we use an IANA parameter that create a parameters.arpa - Other Issues: We need to cleanup the text and we need to do a lot of coding - We need to address offline use case * Adding a “not available now, retry in XXX time period” * Still need to solve the SSID selection problem - We shall also provide privacy considerations Florin B: Can you provide some details about the SSID selection ? Eliot: How do I identify the SSID that supports BRSKI ? Dan: Maybe you can define a pre-association blob in the advertisement Eliot: We might not want to use something protocol-specific Florin: What is the use-case that you are trying to address Eliot: Even if you use AQNP the selection of SSID is still a problem Karen: It seems that you are referring to the Policy Eliot: Maybe we need a bloom filter - you might reduce your hunt considerably without getting into Policy 7. draft-pala-eap-creds Max Pala (15 min) - Thinking about this. Presentation to see if WG is interested - Not ready for adoption - Securing managing credentials is problematic - 3 phases of the protocol - Simplify the messages Joe: One thing from the chairs. We are making progress on our work items. It may be a good time for us to get together with the AD who is coming in and see what the potential is. We have a number of proposals that are coming in that are somewhat similar. All trying to address slightly different problems but the theme is similar. We should start looking at this. We will chat with the AD to see their view Florin: What type of credentials are you trying to manage Max: We want to be generic than just certificates Elliot: Side meeting on Wednesday. Lot of back and forth flows in particular order. All these sort of conditionals. If you subsume all these methods, I am not opposed, but think about whether it is the right thing to do. Your document will get very very big.