Minutes IETF101: emu
minutes-101-emu-01

IETF 101 EAP Method Update (EMU) Minutes
2018-03-19 1550-1720

========================================
Chair: Joseph Salowey
Note Takers: Mohit Sethi
========================================

Note well. Jabber Scribe

All charter Items have presentations

John Mattsson: Using EAP TLS with TLS 1.3

John: EAP-TLS is widely supported for authentication in Wi-Fi
Also used in cert based in auth in MultiFire
5G just standardized but not yet deployed

TLS 1.3 is a complete remodeld of the handshake

Update text.

EAP-TLS 1.0, 1.1 and 1.2 flow

Resumption is different

PSK auth SHALL Not be used except of resumotion

Use NewSessionTicket message containing PSK and other parameters

Bernard: If you don't know and you start that, then you are going fail. There
is a catch.

John: There is no way of knowing that Server supports privacy.

Elliot: If people are doing RADIUS proxying, encrypted certificates can be a
problem.

Alan: Issue is that either you do all of it or proxy all of it. Looking at
certificate for radius proxy is typically not done.

Elliot: We have a use case where we are considering this. Considered a benefit
or negative. Proprietary at the moment. May not be for long.

Jari: Are these use cases current or future.

Alan: Watching the traffic and then proxying or not peaking inside of EAP. Hard
no. If you want to terminiate EAP. That is more possible. That is outside the
scope of EAP. Certs is okay, let me look you up in LDAP. That is fine.

Fragmentation.

Alan: Separate document

Mohit: 1.3 remain in this document. 1.2 can be a separate document.

John: Omit certificates that you know that other end-point knows about. 1.3 you
can omit any trust anchor.

Cached information extension. Work in progress on compression.

OCSP TLS 1.3 changes.

WG adoption? Take to the list.

----------------------------------------------------------------------------------------

Jari: Presenting 2 drafts.

Bug fix and small piece of functionality.

Deployed but usage is still not at that level.

You could directly authenticate with EAP in 5G.

RFC5448bis. A small update of EAP-AKA'.

Could update security considerations.

Binding context: Can cause inter-operability issue. Good to update reference.

Ben: You could use all the identities

Jari: But need exact bits on both sides

Sessiond-Ids issue fixed

John: Update reference in a future proof way.

Margaret: There needs to be IANA registry that 3gpp updates. Or if they have a
registry:?

Jari: Goes into key calculation.

Alan: Update the Sess-ID in two places.

Jari: fairly urgent. Need to get this ready soon. Co-ordination piece is under
control.

Margaret: It's been 15 years. security considerations should be updated. We are
better now.

Joe: NO objections to adoption. Take it to the list.

Jari: Optional new functionality. Perfect forward secrecy. Reported cases of
intelligence agencies stealing keys.

Backwards compatible extension to EAP-AKA'.

Intelligence agencies have to do more.

Discussion in 3GPP. Think that this is a reasonable way. Other methods out
there also. Rely on high-quality keys in local network.

IPR notice. 5448.

Perfect Forward Secrecy is something in phase. If we complete this in
reasonable time. They could take use.

We should enhance our protocols.

Less urgency. Co-ordination is important and ongoing.

:arran cudbard-bell Long pending issues. IMSI number is revealed initially.
Appetite to fix that problem.

Jari: That is being fixed.

John: Mandatory to support 25519 to encrypt identity.

Alan: Session identifiers for fast re-authentication.

5247 says EAP methods must define.

Perhaps add to PEAP.

Non-TLS based EAP methods cannot use the same info.

Sessid-iD needed for.

Bernard: IF there was an IANA. Establish a registry? So that we don't have to
do this again.

Updates 5247. Will get it then next week. Could be published immediately. If
there are IANA registry.

Elliot: WOrking on onboarding of little and big things.

Most of our stuff working in ANIMA working group or OPS area.

Trusted introduction.

5-8 bytes. Minimal processors.

802.11u ANQP extension.

Outer TLS. Defer cert validation.

Create EAP method? someboday might do without wrapping in TLS.

Create TEAP TLVs.

How do to intermediate result.

TEAP has no deployment

Alan: EAP is probably the right thing. Some TLS method is probably the right
thing. TEAP is the right thing.

Bernard: All the dependancies. What you are likely to have in your use case.

Elliot: Want to have answer for other use cases. Ring door bells create their
own AP.

Alan: Not having manufactured ligth bulbs. This how we know how to do it right.
If you don't have CPU, you should be not be on the net.

Elliot: They want to minimize amount of code that they cannot re-use. Heavier
the ANIMA or EAP part is.

Nancy: Been working with EAP. If we are going to Wi-fi. Definition of 802.1x.
Addition is that BRSKI request-response. Add into TEAP, voucher request.
Messages that we put in there is for only cert enrolment. Where as EST is more.
Should we extend TEAP to do what EST does or extend.

Margaret: Trouble understanding the picture. We might say yes, or we might go
to the MASA.

Max-Pritkin: BRSKI into this. ACE is taking it into constrained. Coverying the
use case of 802.11.

Elliot: Possibilities. Client stack is compartmentalized. How to pass 1 or 2
bits of information that would be useful to the client.

Jim: Going to a pain.

Margaret: Sounds complication. Could be incrementaly deployed. They don't have
to get the EAP infrastructure. If not done, you would need other Wireless APs.
Most employes would not be happy about it.

Elliot: MAC authenticated by-pass. Cisco uses. You might end up getting
sandboxed.

Margaret: EAP extension support?

Max-Pritkin: How does the device know it is in the right spot or not?

Elliot: EAP can send soft fail. Server can try other things.

Jari: Interesting problem space. Not sure about the technical details. Often
useful. EAP for authentication. Other mechanisms for delivering configuration
information. That is the advise. Clean stack in some sense. Enrolment is fine.

Elliot: Use case hitting us hard. Don't have DNS but have EAP. Planning to use
CoAP RD. Need one little hook. Everybody has their own little hook.

Margart: MOre nodes that are looking for DNS and NTP.

Jari: Tons of ways of discovery. Not a tractable problem. we can not do dns.
but we are doing certificates.

Margart: Will the other stuff work in non-EAP. Can follow but not implement.

Elliot: Boil the ocean. Broad industry solution. Up hill lifting. Work with
IEEE in this. Thanks Dan.

Dorothy (HP): .11 working group would be delighted to hear about. What is not
addressed.

Joe: Need to figure out what is the right direction.

Elliot: If interested. Drop an email. With advice on channel binding.