Minutes IETF113: emu
minutes-113-emu-01

Administriva

• Notes: Jan-Frederik Rieckersm

WG-Documents

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

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

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

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

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

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

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.