Minutes IETF103: emu
minutes-103-emu-01

EMU - Boromphimarn 1/2 - Monday  16:10-18:10
Jabber Scribe: Jim Schaad
Chairs: Joe Salowey, Mohit Sethi
Note taker: Mohit Sethi

John: Presenting EAP-TLS with TLS 1.3

2 things we decided to change: Session-ID
and Empty TLS Record
This is the best we can do aligning with RFC 5216
We have figure of basically every error case. We don't have case for client
rejecting session. Do we want such a figure? John: Can we do something more
about the identity sent in the first message. Should we mandate Anonymous NAI.

Jim: That is standard behavior
John: Should we then make it MUST in the draft?
Jim: Yes
John: Should we give guidance or references on how implementations should
mitigate attacks on earlier versions of EAP-TLS. Joe: Hesistant to include
things about previous version of TLSs. Jari: Struggled with the same thing in
EAP-AKA`. If there is a good reference to point to, you could just handle the
things that just apply to your protocol. Elliot: If there are attacks against
TLS 1.3 that would not be mitigated by advice given in Security Considerations
of this document. John:Should we reference the draft in Using TLS in
Applications (UTA) working group. Elliot: Add a reference. But don't re-do it.
Elliot: Some of the attacks on TLS are browser related. A line or two on
non-browser risks would be nice. There is a sort of blanket ask to move to TLS
1.3 without justifying reasons. You are the boy who cried wolf again. Darshak,
Jim and Daniel commit to reviewing John: Jouni had implemented an earlier
version Joe: Need more reviews and implementations to inter-op with

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

John: Presenting EAP-TLS with large certificates

Need more reviews. Both drafts are on github. You should look there and open
issues.

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

Jari: Presenting RFC5448-bis

Things we missed or things that need to be fixed
Talk about pervasive monitoring and privacy.
Got comments.
General status. Now really in sync with 3GPP specifications.
Peer-Id and Server-Id is the empty string. Chose to use the empty string. I
don't think it is a problem. Many implementations do not use. Joe: Maybe check
if ABFAB is using these identities. May not be relevant for your case. Jari:
New section 7.2 on discovered vulnerabilities. No reference on fair and
balanced attacks. Russ and Mohit to review during WGLC

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

Jari: Presenting EAP-AKA` PFS

Not a working group item but on the charter
Taken into account reviews and discussion
More detailed and clarified use of negotiation process.
Don't wait for everyone to deploy but do not penalize for those who have not
yet deployed. Jari: DoS resistance Russ: Don't remember where the MAC check
falls and where the MAC key comes from. It would also affect this. Jari: Higher
quality keys exported. But MACs use other keys. Russ: MAC is dependent on the
base AKA` authentication. Jari: Yes Jari: Need feedback. See this as WG
document? We might be able to stick this in and have affect on people's
security and protect from organizations that want to spy on us. Some interest
from our side and another manufacturer working on chipsets. We might actually
get this deployed if we do it. I would love to move forward. Joe: How many
read? Hum if you support adoption: Hum in room Hum if you object: None Joe:
Will confirm on list

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

Tuomas Aura: EAP-NOOB

Deploying of Wi-Fi appliances
Scanning QR codes or dynamic NFC tags.
Don't have to do scaning everytime.
Different from current EAP methods that require pre-registeration.
Elliot: Great work. Can use slides. Can we use EMU wiki
Joe: They are not chartered items
Dave: Talk to them all. What QR code do you present at all. User is going to
pick one. That is great. The peer knows which one it was. Aura: Important that
is delivered to the right Qr code. Erik: Is the AAA server authenticated. How?
Aura: Yes, there is mutual authentication. Mariko: Do you need new code on the
device? Is there requirement for IoT device vendors? Aura: Implementation on
device required new code

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

Elliot Lear: EAP-TEAP-BRSKI

Dan: Do you need some NAI decoration for routing to the right AAA server
Elliot: We will steal the idea from EAP-NOOB
Dan: If TLS is unauthenticated. Why do you need EAP-TEAP. Why don't you just do
EAP-BRSKI Brian: Provisional authentication is only on the client. BRSKI
assumes that Server has trust anchor. That is the BRSKI model defined. Dan:
Don't understand EAP flows. EAP is a lock step protocol. Dan: Overloading TLVs?