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 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.
Presenting: Alan Dekok
Already in the last version of the draft, not much discussion on
this
Second issue: TTLS+PAP
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.
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.
Presenting: Dan Harkings
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
Presenting: Meiling Chen
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
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.
Presenting: Yuan Tian
Validation
Looking into collaboration/contributions. Current plan to continue
work on this and then request to adopt as WG item.