Presenting: Jari Arkko (JA)
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, extra byte not needed/helpful. Only X-coordinate are transmitted, so sign does not matter anyway John: Can live with both, Mohit: 3gpp already uses 33 bytes,
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.
Presenting: Alan Dekok
Mohit: Tim: MAC OS lets you configure it, not sure if it works Alan: 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 problem.
Alan will update the draft, then this should be good to go.
EAP is becomming a container for several messages, e.g. provisioning, ...
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, relying on standard internet protocols. Can you elaborate how to do that? Alan: 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 likelihood 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: update the document to include more use cases, EAP has high complexity 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: Super frustrating to connect, even to the ietf network. Scoping it to user devices would be good, maybe make different EAP
Joe: Not go for adoption call, maybe take it to the list to have more discussion about it.
Presenting: Dan Harkings
Mohit: 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 revving TEAP, but we need this first.
Dan: CSR Attrs TLS 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
Presenting: Meiling Chen
Mohit: This would be a separate EAP-Method, not EAP-TLS
Show of hands: Have you read the draft? 8yes/21no
Joe: Call on the list.
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-Frederik was looking for some feedback.
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.