Minutes IETF113: emu
minutes-113-emu-00

Administriva

• Notes: Jan-Frederik Rieckers

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, 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.

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
• Most implementations are ok, pending the issues good to publish

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.

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, ...

  • 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, 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.

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:
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

EAP-IBS

Presenting: Meiling Chen

• Use cases: IoT-Devices and devices without CA certificate support
• Implementation exists
• Uses Extensions
• Request for this to become a WG item

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.

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-Frederik 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.