## Administriva {#administriva} * Notes: Jan-Frederik Rieckersm ## WG-Documents {#wg-documents} ### AKA-PFS {#aka-pfs} Presenting: Jari Arkko (JA) * Hanging around right now, waiting for opportunity to put it in use * -06 submitted, reference update, PFS/"forward secrecy" terminology * One open issue with disucussion on ML about encoding of the public value, see ML archive. More input from WG/others needed John Mattsson: Fine with 33 bytes, many people already use it, no objection. (Clarification question from JA: Wording in current draft ok? John will check.) Dan: Only use for additional byte is the sign of the point, extra byte not needed/helpful. Only X-coordinate are transmitted, so sign does not matter anyway John: Can live with both (32 or 33 bytes) Mohit: AKA will be used in 3gpp, 3gpp already uses 33 bytes, follow what they are using, probably AKA-PFS will not be used in super-constrained environments, extra byte not an issue Joe: Suggestion: Finalize the specification, then start WGLC. Nicholas Gajcowski: Library use may be an issue, libraries may expect different sizes. JA: Spec will be clear, no ambiguity then, interface to library should be clear. Jonathan Hammell: For 32-byte representation you may need to calculate the Y for library use. D: Have to do the calculation anyway. ### TLS EAP Types {#tls-eap-types} Presenting: Alan Dekok * for multiple implementation it is 'aledgedly' good to go * Open issue: Disallow only client certificates without inner authentication method. * Already in the last version of the draft, not much discussion on this * Second issue: TTLS+PAP * Only "half" roundtrip, no protected success/failure indicator. * Problem with sending a session ticket, unexpected message, could lead to reject * Suggestion: Update Document to continue TLS until EAP-Success/Failure * Most implementations are ok, pending the issues good to publish Mohit: Using only client certificate seems ok, but if we forbid, we may not be aware of niche deployment, send a heads up with the change over mailinglists to alert of that change? Tim: MAC OS lets you configure it, not sure if it works Alan: PEAP specs are unclear, using only certificate is configurable in my software, but we have already a method for using only a client certificate. Forbidding this would prevent people from using this and having problems. Alan will update the draft, then this should be good to go. ## Other drafts {#other-drafts} ### EAP usability {#eap-usability} * not a lot to discuss, only minor updates * Not just a way to configure EAP, tradeoff in cost * EAP is becomming a container for several messages, e.g. provisioning, ... * Provisioning probably good to use for administrators, but gets more complicated to implement * Question: is this ready for WG adoption? Elliot: Looked into this a while ago. Want to address one point: In IoT we don't have user interface, so we need a way to provision a certificate/trust anchor, relying on standard internet protocols. Can you elaborate how to do that? Alan: Intention is not IoT with no UI/..., that's not the primary focus. Phone/Laptop has probably two different network interfaces, could rely on DNS/HTTP/... to provision the EAP configuration. Draft provides a method to easily set up EAP networks. Problem is that the error messages are usually not verbose Bernard: EAP not suitale for transfering much data, better to do it via other methods Alan: Configuration may include Certificates/Chains, up to 64k data seen, not suitable for EAP Bernard: Will improve likelyhood that configuration will succeed if using second network connection Eliot: Two directions to take. Direction 1: Scope the document to cover only certain use cases. Direction 2: see if we can come up with something that covers both (IoT and non-IoT). Pushing to other layers, complexity spreads to other places. How to insert a trust anchor without layer 3 protocols. Not saying "not do this draft", but think about if we want to tackle the problems together or apart from each other. May open other attack vectors, need to think about that. Tim: In favor of this. Super frustrating to connect, even to the ietf network. Scoping it to user devices would be good, maybe make different document for IoT Joe: Not go for adoption call, maybe take it to the list to have more discussion about it. ### DPP {#dpp} Presenting: Dan Harkings * WiFi-DPP uses a raw bootstrapping key to establish trust * Idea: Use this key in EAP, make use of TLS raw public keys * Use this inside TEAP, make the TLS exchange, use PKCS#10 exchange to provision client certificate * Question rough consensus for adoption? Mohit: Comment about 8773: labled as experimantal, not many libraries implementing this. Russ: It is still experimental Bernard: Mention of identity response in a way that never has been standardized. Never documented this, might be a good idea to document it. Elliot: good idea to move this forward. We should consider reving TEAP, but we need this first. Dan: Regarding TEAP: CSR Attrs TLV does not exist yet, move forward with TEAP update Joe: Maybe some things to resolve with tls, clarify if this is blocking. If not, go ahead with adoption call. Mohit: For adopting this. TLS issues should not be blocking. Would be good to have more TLS eyeballs on it Dan: Inserting the DPP-Key into the tls key schedule problem, tls wg suggested using 8773/7250 ### EAP-IBS {#eap-ibs} Presenting: Meiling Chen * Use cases: IoT-Devices and devices without CA certificate support * Implementation exists * Uses Extensions ServerCertificateType * Request for this to become a WG item Mohit: Note: This would be a separate EAP-Method number, not EAP-TLS Show of hands: Have you read the draft? 8yes/21no Joe: Call for adoption on the list ### EAP-NOOB-Observations/EAP-UTE {#eap-noob-observationseap-ute} Presenting: Jan-Frederik Rieckers This draft examines certain properties of NOOB and attempts to offer an evolution on the protocol that does things like uses CBOR instead of JSON and properly has a version # ;-) There was no time for questinos. This is part of graduate work, and Jan was looking for some feedback. ### EAP-Creds {#eap-creds} Presenting: Yuan Tian * Problem: Different type of credentials that need to be provisioned * EAP already used for different access methods * EAP-CREDS will rely on the security of the communication channel * Three phases: * Initialization * Provisioning * Validation * Looking into collaboration/contributions. Current plan to continue work on this and then request to adopt as WG item.