Notetakers: Janfred & Ethan
Three docs are in the RFC Editor's queue. EAP-EDHOC was just submitted
to the IESG.
MCR presenting.
Heikki: Should the EAP-TLS without client authentication have its own
EAP type?
MCR: That is not a general concern, but it may require a lot of changes
in software.
Heikki: Should other components be aware that this is an EAP-TLS
handshake where the client did not authenticate?
MCR: The idea of this is that it is heavily localized; we wouldn't use
this on something like eduroam. The eap.arpa realm is always handled
locally, so there aren't a lot of components that need to be aware.
Janfred: Server auth could also be thrown out because the client doesn't
have any trust anchor for the server cert. We could do anonymous TLS as
a vehicle to get an encrypted Wi-Fi channel to do the onboarding
afterwards.
MCR: Potentially you could have server certs that the client has anchors
on, in the future. Prefer to do the server auth even if the client can't
do it. If you have a number of networks to join, you can check if it has
the same server cert (one you already know), as a test if you should
connect.
Joe (as participant): Maybe we want a different EAP method so that the
device knows it is going on a provisioning network, and that maybe it
could have different security/auth expectations.
MCR: Already it is not like the client is unaware of the fact that it is
hopping on a provisioning network, but another type could be good.
Alan: If doing EAP-TLS and not using a client cert, and using onboarding
at the onboarding endpoint, that is enough. Once you have a network
(post-onboarding), you can then use web PKI.
Alan: There are cases this cannot be used because the local network
cannot do a captive portal. However, there are still situations where
this is useful, and we should not be hindered by this fact.
MCR: Yes, that is why having the captive network is good so that you can
get on there and get up to speed.
Alex: +1 to Janfred, Server cert validation maybe not necessary, similar
to current open Wi-Fi captive portals.
MCR: Ongoing work e.g., DPP, including Bloom filter in beacon to find
out if the network accepts you based on MAC address
Mark: Discussion with FIDO Alliance to deliver FDO voucher using SCIM,
may be equivalent to BRSKI.
Regarding network selection: WBA has allocated a bit in RCOI specific
for a network with short-lived credential to have connectivity to
provision long-lived credential?
Heikki: Sounds good that server cert validation is skipped, but now we
have EAP-TLS without any authentication
MCR: Rather than stripping auth completely, I'd just remove the
certificate validation. Maybe the cert can be validated later on in the
onboarding process.
Joe (as Chair): Quick question about whether or not this is of interest?
Mark: If we end up with something where no end is authenticated, we end
up with something similar to OWE (opportunistic wireless encryption).
Joe: We have 11 "yes" (and no "no") in the show of hands, so looks like
this is of interest to WG, to be confirmed on the mailing list.
Bart Brinckman presenting.
Alan: For your information, there is a lot of discussion in the radext
WG about preventing abuse. Would recommend following the radext mailing
list for that topic, although it may be outside of scope in emu and more
for radext.
Janfred: Channel Binding in RFC 6677 is not preventing all attacks
that are given or that could come to mind. Have you looked at that? What
are your thoughts?
Bart: We do have a working prototype, but if there are existing attack
vectors then we are interested to follow up and look at those.
Prototypes have channel binding implemented. Prototypes are currently
closed-source and not yet available. We are working on getting something
available/open-source.
Joe (as participant): There are different types of tokens in
privacy-pass; be more explicit aboout that in the draft.
Guilin: What does identity abuse mean?
Bart: How do you identify on a network that a user is abusing a service
(auth or other), and how do you deny them this. Focuses on identifying
users that exhibit bad behaviour.
Guilin: Is this like a DDOS attack?
Bart: That could be considered abuse. For example, performing failed
auth several times.
Alex: Currently there is no mechanism to prevent ongoing abuse, other
than just session-to-session identifying. Is there a different method to
flag them (other than using MAC addresses) to continue to deny them?
Bart: I agree. However, this problem exists for other EAP methods
already.
Alex: The difference with other EAP methods is that there is a techincal
solution. With this, there is not, there is no way to group these
sessions together.
Bart: If you want the network to have a permanent user ID, then you
would not use EAP-PPT.
Mark: I think moving forward using CUI for various activities won't be
available.
Alan: Would be easier, to block users at a RADIUS or policy level.
Eduroam has some policy for this. I don't know that this is a problem
that EAP-PPT has to solve.
Alex: The tokens and the MAC address cannot be used to block users since
the token eventually goes away, so you cannot track this.
Bart: The token was generated using attestation, which relies on the
attester providing some auth details for that user. So there is that
additional layer that has provided some level of auth alreadey.
Joe: There is this conflict between privacy and the ability of tracking
the user. Do we want the behaviour of tracking the user? There are
tradeoffs.
Joe: Is there anyone willing to review the drafrt?
Alan presenting.
Joe: The important question is whether people are actually willing to
implement and use this? Otherwise we might put a lot of effort in, and
no one uses it.
Alan: Elliot has a lot of use cases, e.g., the distinction between
machine and user authentication and the combination of this.
Joe: It would be good to put down requirements and use cases as
reference for goals. This doesn't need to be formal. Also look at
security goals if those are necessary.
Alan: Will confirm with people and add things to the draft.
Heikki: Plan is to be compatible with usual Windows use case as with
TEAPv1?
Alan: Yes, we'll update the protocol, but the use cases seem to be
popular, TEAPv2 needs to support that.
Joe: Let's first look at the requirements, then we can look at
timeframe.
(silence)