EMU @ IETF115

Notes: Janfred

Administrivia (5 Min)

No addition to the agenda.

Certificates issues (20 Min)

Alan DeKok presenting.

Had a lot of discussion about usage of certificates in EMU. Question:
Where to go next?

Joe: Two sides of usage (server and client side), what is the scope?
Alan: Both. Anything.

Joe: Authentication of server certificates often Trust-On-First-Use with
no concrete information. Don't know if there is a good solution to this
problem?

Stefan Winter: speaking for eduroam: Pushed users to use provisioning
tools. Try to make it impossible not to use them. With new WiFi-Alliance
standard "Do not validate" setting in Android is now forbidden.
One way to do this is to configure RADIUS/EAP-server to accept only one
special outer ID, so clicking on network and entering passwords does not
work -> Users then use the provisioning tool.

Joe: What CA/Servername requirements are you using?
Stefan W: Institutions can choose freely, many choose a commercial CA,
some have a private CA, some have a self-signed user.
Alan: This is a big step forward. Did a test few years back and got a
lot of credentials with bogus AP.

Massimiliano: In cable network, managing credentials is difficult.
Different sets of credentials, one to get on the network and one for
user-level actions. The first one is often forgotten.
We proposed protocol EAP-CREDS to use EAP for provisioning credentials,
which makes management of credentials easier.

Karri: One topic: How to separate problems. Problems with RADIUS servers
(e.g., expiry) can be handled with automation. But user devices are a
problem, especially if not in Mobile Device Management. Finding a good
way to provide client certificates to those devices is hard.
Stefan W.: Problems with EAP is it is used to get online. Therefore,
there's a problem between Online vs. Offline configuration. Offline
configuration (e.g., with CAT tool) works well, but it is not very
convenient compared to fetching a website to get your profile.
Alan: Some issues are addressed in the draft: Most devices have two
network devices (e.g., Mobile network for Phones or Network at home
instead of corporate network access)
It may be useful to define something like @eap.arpa (see ML),
unauthenticated EAP-TLS as onboarding network. Feedback from Vendors:
RADIUS-People don't talk to Network/DNS/Webserver people, difficult to
do in some environments. Technically simple, administratively hard.

Deb: Are you talking about devices or people? (capable devices?)
Alan: Generally people's devices (phones/laptops), IoT is out of scope.

Deb: You don't want to go down the rabbit hole of PKIX?
Joe: We are in the PKIX world because of TLS.
Alan: Problem: Where does the configuration come from? (e.g., SSID,
EAP-Method), which is typically not part of certificate.
Deb: Also what's the specification for naming? E.g., CA/B-Forum? We're
not talking web?
Alan: Most people use web server certificates for RADIUS servers which
does not completely comply with the CA/B-Forum policies.
Deb: Sounds like public/private CA mix?
Alan: Yep.
Deb: Both have their issues. If you do public, you don't have to deal
with the trust store.
Joe: This introduces new problem of how to validate certificates.
Deb: Getting client certs is also a problem?
Alan: Yes. It's expensive to get an intermediate CA for your own users.
You can't get a certificate with NAIRealm in it, as the CA/B Forum will
reject this.
And you cannot get certificate with custom OIDs or specific extended key
usages.
Deb: What draft is this in?
Alan: eap-onboarding and eap-configuration, look for my name.

Josh: I heard mention of DNS/eap.arpa, what's that about?
Alan: TEAP does provisioning over TEAP. I don't want to define "IP over
EAP", it just smells. Instead have a onboarding network accessible with
unauthenticated EAP-TLS with a specific identity.
Stefan W.: for eduroam, there is a growing understanding that passwords
are on the way out. The new service is with a portal where you log in
with web credentials and get a TLS client certificate for EAP-TLS. When
you download your client cert, you also download the whole
configuration.
Alan: There's also the open possibility of Passkey support (essentially
raw pub/priv key pairs).

Karri: Some devices have a common certificate store, if you install a
custom CA it can be used for everything else es well.
Most RADIUS servers use web server certificates and no one cares.
If a certificate expired, devices with the wrong configuration
continued to work.
Alan: Additionally: Only reply on failure is "Failed." We need to
improve the user feedback.
Janfred: How do devices know the correct server name for certificate
validation. Can't they simply use the realm of the NAI and check for
that.
Alan: See the configuration document. Theory: Everyone has a reasonably
capable device with a cert store. The device connects to a web server
and downloads a configuration file.
Joe: Is there work in the Wi-Fi alliance?
Stefan W: There is a long expired draft. It got no interest in the IETF;
every vendor has their own thing, but Wi-Fi Alliance had no interest.
Joe: Alan has a couple of drafts. It would be good to have more people
to look at this.
Vadim: What's suggested is that you are authenticated as aguest, then do
the config, then connect again. In some places that might not be
acceptable to have untrusted devices on the network, even with aseparate
VLAN for onboarding.
Janfred: Question to discuss: Is it safe to assume that we have a second
channel or should we also provide methods for in-band provisioning.

Update for EAP-AKA

Jari Arkko presenting.

From the authors' view there are no open issues.
No direct 3GPP link to this but there is interest from vendors to finish
the spec.

Heikki: Does it interoperate with IMSI privacy extensions?
Jari: Not aware, should not in general, let's talk afterwards. Could you
send some links to this?

Joe: Seems ready for WGLC, IMSI privacy seems not to have an impact on
this.

EAP-DIE (15 Min)

Josh Howlett presenting.

EAP-DIE is about deprovisioning. Alan was talking about provisioning.
I'm talking about the reverse.

Usually two methods of management: Device Management and manual
administration.

No draft yet, for now just here to get feedback.

Stefan W: We looked at the notification 10 years ago. This is
underutilized, you will get a wide variaty of reactions from different
supplicants.
Vadim: Had trouble just getting on Wi-Fi. Can you use this to send debug
information?
Josh: No, since we don't have the cryptographic keys needed for the MAC,
so you can't be sure the message came from the EAP server.
Heikki: Profile lifetime is not necessary device lifetime if profiles
get transferred automatically to a new device

Joe: Concern with the state machine, probably some key material things
to work out.
Janfred: In regard to question 4 (Limit due to requirement for previous
successful auth): it would be good to just disable the configuration
instead of deleting it, so if the timeframe is too short and people come
back, they don't have to get new credentials.
Joe: Overlap with provisioning?
Matthew: There are other cases when you want to send messages. Do you
want to disconnect this from the message, so supplicants don't show the
new expiry date every time?
Vadim: Do you plan to differentiate between machine auth and user auth?

Joe: Will have further discussion on the list.

EAP-UTE (10 Min)

https://datatracker.ietf.org/doc/draft-rieckers-emu-eap-ute/

Janfred presenting.

Was presented in Vienna, no feedback so far.

Joe: Probably an item to post to the list. People with experience may
not be present here, since it is a niche-protocol.

Bootstrapped TLS Authentication (10 Min)

https://datatracker.ietf.org/doc/draft-ietf-emu-bootstrapped-tls/

Dan Harkins presenting.

There will be effort to have implementations of this.

Joe: Will have more discussion on the list to determine how to move this
forward.