Re: [Emu] New I-D: A new EAP method called EAP-FIDO

[Michael Richardson]

Dan Harkins  wrote:
>   RCM means that MAC addresses can't be relied upon anymore; good. The
> solution is not EAP-TLS in the home though, it's getting away from the
> "single passphrase per SSID" model that Wi-Fi came up with 20+ years
> ago and still cannot move beyond. For the record, it's possible to send
> a password identifier in the WPA3 exchange to support multiple
> credentials on a single SSID (it's part of the 802.11 standard) but the
> largest mobile phone company refuses to support it so it's kind of
> dead-in-the-water.

I didn't know that WPA3 supported a password identifier (I guess: a
"username" concept).  That's pretty significant I think.
Do you know why "largest mobile company" thinks it is a bad idea?

--
Michael Richardson , Sandelman Software Works
 -= IPv6 IoT consulting =-  *I*LIKE*TRAINS*





signature.asc
Description: PGP signature
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] New I-D: A new EAP method called EAP-FIDO

[Michael Richardson]

Jan-Frederik Rieckers  wrote:
> Firstly: deleting the EAP-specific configuration (as in: "Dear client,
> I don't know you, please stop asking").  This can be as simple as
> sending a simple message, but has the problem that faulty
> configurations in the beginning can't be debugged, because the moment
> the client connects it gets the delete request and deletes the profile.

:-)

> But actually I don't know if **provisioning** the credentials in-band
> is such a good idea.  Because, in order to provision the credentials,
> the user needs to prove that they are authorized, and how would they do
> that?

Is the user provisioning a new device, or is the network provisioning a new 
user?

> I admit that with the current idea of the protocol flow the
> OOB-registration adds a small layer of complexity for the
> administrators, but I gather that it will be much more easy for the
> users.  And the additional workload for the provisioning is well
> invested

Agreed.

> With the current movement the FIDO alliance is pushing this is actually
> a great step, because the FIDO Passkey that is already provisioned for
> logging into the account in the web can now simply be used for network
> access as well.

I hope this turns out to be true.

--
Michael Richardson , Sandelman Software Works
 -= IPv6 IoT consulting =-  *I*LIKE*TRAINS*





signature.asc
Description: PGP signature
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] New I-D: A new EAP method called EAP-FIDO

[Alan DeKok]

On Oct 31, 2023, at 6:28 AM, josh.howl...@gmail.com wrote:
> Playing Devil's Advocate and going a bit OT: this is an excellent goal, so 
> why stop at EAP-FIDO?
> 
> We could define a similar validation logic for the existing TLS-based methods 
> to obtain the same benefit. For example:
> * The value of the EAP-Identity/Response NAI realm is a well-formed FQDN
> * The phase 1 server certificate is issued by the WebPKI
> * The phase 1 server certificate's name takes a value that corresponds to the 
> NAI realm
> 
> The supplicant trusts the server if the certificate is valid and the realm 
> matches (hand-wave) the certificate name. I think this is the moral 
> equivalent of section 4.2.5 with Option B in Appendix B. The same validation 
> logic could be used in phase 1 of the existing tunnel methods, and the inner 
> method (e.g. EAP-FIDO) executed in phase 2 as usual.
> 
> It makes no sense to update the existing methods, but perhaps it could be 
> offered as guidance for existing named methods (and referenced in new methods 
> where it makes sense).

  I think that's a pretty reasonable suggestion.  It works for the web, email, 
and pretty much every other TLS-based protocol.  Why not EAP?

  I would only add to that that any such method should be limited to just 
sending a clear-text password.  There's no reason to continue allowing MS-CHAP 
and CHAP.

  Alan DeKok.

___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] New I-D: A new EAP method called EAP-FIDO

[Alan DeKok]

On Oct 31, 2023, at 3:12 AM, Jan-Frederik Rieckers  wrote:
> But actually I don't know if **provisioning** the credentials in-band is such 
> a good idea.
> Because, in order to provision the credentials, the user needs to prove that 
> they are authorized, and how would they do that?

  That was one of the issues raised about TEAP.  The answer there is "use 
passwords to provision certificates".

  That's pretty much how passkey works on the web,  So it's not a terrible 
answer.

> Send a password together with their provisioning request?
> This is not secure, since the user can again type in a wrong domain and this 
> way unintentionally give the password away to a malicious third party.

  If the realm is verified against the server cert, and the server cert is 
verified against a known CA, it's less of an issue.

> And regarding the "oh, but now the RADIUS admins need to talk to the web 
> admins" argument:
> The RADIUS admins already need to talk to the IdM admins to gain access to 
> the user database (esp. if password-based authentication methods are used).
> So if the RADIUS and web admins don't want to talk to each other: fine, they 
> don't need to. The web admins just need to provision the FIDO token and write 
> them back to the IdM database and the RADIUS admins can access the FIDO 
> public keys from the database.

  I agree.

> With the current movement the FIDO alliance is pushing this is actually a 
> great step, because the FIDO Passkey that is already provisioned for logging 
> into the account in the web can now simply be used for network access as well.

  That is my hope.

  Alan DeKok.

___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] New I-D: A new EAP method called EAP-FIDO

[josh.howlett]

> For the current EAP-TLS based methods, the "service" of putting on the
> harness and hooking you in is not provided. And that is exactly what I want to
> achieve with the TLS part of EAP-FIDO. The users shoulnd't see any of the
> certificate check parameters, it should be implicit and that is where we
> improve the security of the EAP-TLS based method (Details:
> see last paragraph of this mail)

Playing Devil's Advocate and going a bit OT: this is an excellent goal, so why 
stop at EAP-FIDO?

We could define a similar validation logic for the existing TLS-based methods 
to obtain the same benefit. For example:
* The value of the EAP-Identity/Response NAI realm is a well-formed FQDN
* The phase 1 server certificate is issued by the WebPKI
* The phase 1 server certificate's name takes a value that corresponds to the 
NAI realm

The supplicant trusts the server if the certificate is valid and the realm 
matches (hand-wave) the certificate name. I think this is the moral equivalent 
of section 4.2.5 with Option B in Appendix B. The same validation logic could 
be used in phase 1 of the existing tunnel methods, and the inner method (e.g. 
EAP-FIDO) executed in phase 2 as usual.

It makes no sense to update the existing methods, but perhaps it could be 
offered as guidance for existing named methods (and referenced in new methods 
where it makes sense).

WPA3-Enterprise already defines requirements for server certificate validation 
by supplicants, and Windows 11 applies the same validation logic for all native 
EAP methods and lower layers, so there is precedent (I believe the main 
difference between Windows 11 and the approach outlined above is that Windows 
11 does not require validation of the server name (although this can be 
configured), instead requiring CA pinning).

Josh 



___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] New I-D: A new EAP method called EAP-FIDO

[Jan-Frederik Rieckers]

On 30.10.23 17:39, Behcet Sarikaya wrote:> - The draft talks about Fido 
but there is no introduction to Fido. Yes,

you gave the standards references but I think that is not sufficient.
I have a T2TRG draft:
https://datatracker.ietf.org/doc/draft-irtf-t2trg-security-setup-iot-devices/ 

which has a short description of FIDO which is pretty complicated by itself.


Thanks for the comments.
Adding text about FIDO is definitely needed and still a TODO.
For this first I-D version I just wanted to have a spec of the protocol 
as starting point for discussions.
I'll look into your I-D and the next I-D version should have at least a 
basic description of what FIDO is.


- My second concern is the use of AAA for IoT devices. I mentioned this 
before on some other EMU draft.
I believe that AAA will not work with IoT. The way AAA  servers function 
it will not be scalable to the billions of IoT devices expected to be 
deployed.

I don't understand what you mean by that.
IoT is not a primary focus of this draft, so I haven't put much thought 
into high scalability for billions of devices.


And to me it sounds more like "EAP is not the right thing for IoT" 
rather than "EAP-FIDO is not the right thing for IoT"


I will definitely look into the FIDO Device Onboarding specification to 
see if this can help make EAP-FIDO more IoT compatible.


Cheers,
Janfred

--
Herr Jan-Frederik Rieckers
Security, Trust & Identity Services

E-Mail: rieck...@dfn.de | Fon: +49 30884299-339 | Fax: +49 30884299-370
Pronomen: er/sein | Pronouns: he/him
__

DFN - Deutsches Forschungsnetz | German National Research and Education 
Network

Verein zur Förderung eines Deutschen Forschungsnetzes e.V.
Alexanderplatz 1 | 10178 Berlin
www.dfn.de

Vorstand: Prof. Dr. Odej Kao (Vorsitzender) | Dr. Rainer Bockholt | 
Christian Zens

Geschäftsführung: Dr. Christian Grimm | Jochem Pattloch
VR AG Charlottenburg 7729B | USt.-ID. DE 1366/23822


smime.p7s
Description: S/MIME Cryptographic Signature
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] New I-D: A new EAP method called EAP-FIDO

[Jan-Frederik Rieckers]

On 30.10.23 12:20, Hannes Tschofenig wrote:> you cannot complain about 
the use of TLS in EAP when the EAP method you

propose relies on TLS. The TLS-based authentication is an essential part
of the FIDO solution. Without TLS it is completely insecure.


I don't complain about TLS or EAP-TLS itself.
I complain about the way certificate checks are implemented in EAP-TLS 
based methods.


To put it in an analogy:
We have a wobbly bridge (our TLS tunnel) to cross the dangerous river 
(the untrusted world). You can cross the river any time, but if someone 
shakes the bridge, we fall off (the attacker can intercept and modify 
all traffic, because they intercepted the TLS traffic).
We have a safety rope, that keeps us from falling (the certificate 
check). But we need to put on a harness and hook into the safety rope 
(configure expected Server Name and trusted CA) in order to safely cross 
the bridge.


And as long as no one shakes the bridge, you can cross it and nothing 
happens, even if you're not attached to the safety rope.


Of course we can now say: "But we have security measures, just hook 
yourself into the safety rope", but the users are used to have all that 
taken care of (i.e. if you use a browser, the browser puts on the 
harness for you and hooks you into the safety rope).
They have no idea how to put on the harness. And it's tricky, if you do 
it wrong, you can't even cross the bridge any more because the hook 
blocks the moment you hook into the safety rope (the certificate check 
fails because of wrong parameters).

So it is easier to just leave the harness off.

For the current EAP-TLS based methods, the "service" of putting on the 
harness and hooking you in is not provided. And that is exactly what I 
want to achieve with the TLS part of EAP-FIDO. The users shoulnd't see 
any of the certificate check parameters, it should be implicit and that 
is where we improve the security of the EAP-TLS based method (Details: 
see last paragraph of this mail)



Regarding the key extractor use you describe below: I don't remember
this technique being used by FIDO. I have worked in the FIDO Alliance in
the early days on U2F / UAF but might have missed some more recent
developments.


I don't understand what exactly you are referencing here.
Do you mean the idea to export the FIDO challenge from the TLS context?

I haven't yet had the time to completely and fully read through the FIDO 
specification to analyze if the current protocol specification has 
weaknesses in regard to the clientDataHash that is to be signed by the 
FIDO token. It does not have the same format as specified by WebAuthn, 
but maybe there are some aspects that need to be addressed.



Regarding the benefit of FIDO: I don't think the "main benefit of using
FIDO is the ease of provisioning a credential to the supplicant". Once
you have an authenticated channel, it is trivial to provision new
credentials. There are hundreds of protocols that do that.


And yet we have an app to set up eduroam, because we don't have a 
working provisioning protocol for EAP configurations. Every vendor has 
their own format and a different configuration API (that sometimes 
drastically changes between OS versions).



On the security front I am wondering whether the introduction of this
use case weakens the use of FIDO for the web. In the web case, an
important aspect is to perform authentication and authorization of the
domain name with which the credentials are later utilized. For network
access authentication the domain authentication and authorization is, as
you have been mentioning in the draft and also in your emails, rather
weak. Have you looked into this aspect? Attacks that result from
cross-protocol use isn't uncommon.


The possibility for cross-protocol attacks is definitely a thing that 
needs to be addressed in the security considerations section.


The idea is to have a similar strong bind to the server certificate in 
EAP-FIDO as we have in WebAuthn. How exactly this is achieved is still 
TODO, as outlined in the "Open Questions" section in the I-D.

But this strong binding is essential.

Cheers,
Janfred

--
Herr Jan-Frederik Rieckers
Security, Trust & Identity Services

E-Mail: rieck...@dfn.de | Fon: +49 30884299-339 | Fax: +49 30884299-370
Pronomen: er/sein | Pronouns: he/him
__

DFN - Deutsches Forschungsnetz | German National Research and Education 
Network

Verein zur Förderung eines Deutschen Forschungsnetzes e.V.
Alexanderplatz 1 | 10178 Berlin
www.dfn.de

Vorstand: Prof. Dr. Odej Kao (Vorsitzender) | Dr. Rainer Bockholt | 
Christian Zens

Geschäftsführung: Dr. Christian Grimm | Jochem Pattloch
VR AG Charlottenburg 7729B | USt.-ID. DE 1366/23822


smime.p7s
Description: S/MIME Cryptographic Signature
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] New I-D: A new EAP method called EAP-FIDO

[Jan-Frederik Rieckers]

On 30.10.23 15:55, Alan DeKok wrote:

Today's turnkey EAP provisioning solutions are not *conceptually* dissimilar
to this (often using self-signed CAs with EAP-TLS for mutual authn; and LDAP
to the Enterprise directory to authz the client cert's SAN). The onboarding
would just be transparent for an end-user because of the browser/OS/TPM
integration (so no "installer" to download and execute).

It would be very interesting if the initial registration could be performed
in-band of EAP (using WebPKI).


   That would be very useful.  It's a balance between making the draft useful 
(large, long delay), or getting it done quickly, but perhaps missing features.

   I think the ideal approach is for EAP-FIDO to allow:

* authentication via FIDO as discussed

* provisioning of FIDO credentials

* de-provisioning of credentials.

   The last one is hard, as how do you de-provision credentials if you've 
deleted them, and you can't prove who you are?


I completely agree that **de-provisioning** of credentials should be 
part of the protocol.


There are two parts of that problem (just from the top of my head:

Firstly: deleting the EAP-specific configuration (as in: "Dear client, I 
don't know you, please stop asking").
This can be as simple as sending a simple message, but has the problem 
that faulty configurations in the beginning can't be debugged, because 
the moment the client connects it gets the delete request and deletes 
the profile.


The second part is the actual FIDO credential. If we provision a Passkey 
In-Band, then we need to have a way of deleting that passkey.
From the top of my head I'd say that the server should keep the 
credentials of deleted users for a period of time and when they try to 
log on they get a "pls delete" request. The client ACK's the request and 
then the server can delete the credential.




But actually I don't know if **provisioning** the credentials in-band is 
such a good idea.
Because, in order to provision the credentials, the user needs to prove 
that they are authorized, and how would they do that?


Send a password together with their provisioning request?
This is not secure, since the user can again type in a wrong domain and 
this way unintentionally give the password away to a malicious third party.


Obtain a shared secret to calculate a MAC to authorize the request?
Here we have the Catch-22 again. How do the users obtain the shared 
secret? Via a web portal? Then the user can simply register their 
credential via WebAuthn.



I admit that with the current idea of the protocol flow the 
OOB-registration adds a small layer of complexity for the 
administrators, but I gather that it will be much more easy for the users.

And the additional workload for the provisioning is well invested

And regarding the "oh, but now the RADIUS admins need to talk to the web 
admins" argument:
The RADIUS admins already need to talk to the IdM admins to gain access 
to the user database (esp. if password-based authentication methods are 
used).
So if the RADIUS and web admins don't want to talk to each other: fine, 
they don't need to. The web admins just need to provision the FIDO token 
and write them back to the IdM database and the RADIUS admins can access 
the FIDO public keys from the database.


With the current movement the FIDO alliance is pushing this is actually 
a great step, because the FIDO Passkey that is already provisioned for 
logging into the account in the web can now simply be used for network 
access as well.


Cheers,
Janfred


--
Herr Jan-Frederik Rieckers
Security, Trust & Identity Services

E-Mail: rieck...@dfn.de | Fon: +49 30884299-339 | Fax: +49 30884299-370
Pronomen: er/sein | Pronouns: he/him
__

DFN - Deutsches Forschungsnetz | German National Research and Education 
Network

Verein zur Förderung eines Deutschen Forschungsnetzes e.V.
Alexanderplatz 1 | 10178 Berlin
www.dfn.de

Vorstand: Prof. Dr. Odej Kao (Vorsitzender) | Dr. Rainer Bockholt | 
Christian Zens

Geschäftsführung: Dr. Christian Grimm | Jochem Pattloch
VR AG Charlottenburg 7729B | USt.-ID. DE 1366/23822


smime.p7s
Description: S/MIME Cryptographic Signature
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] New I-D: A new EAP method called EAP-FIDO

[josh.howlett]

> From: Alan DeKok 
> On Oct 30, 2023, at 9:53 AM, josh.howl...@gmail.com wrote:
> > It would be very interesting if the initial registration could be
> > performed in-band of EAP (using WebPKI).
> 
>   That would be very useful.  It's a balance between making the draft
useful
> (large, long delay), or getting it done quickly, but perhaps missing
features.
> 
>   I think the ideal approach is for EAP-FIDO to allow:
> 
> * authentication via FIDO as discussed
> 
> * provisioning of FIDO credentials

I am in favour of this. Authentication will be useful without in-band
provisioning.


___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] New I-D: A new EAP method called EAP-FIDO

[Behcet Sarikaya]

Hi Jan-Fred,

I also have some comments of this draft.

- The draft talks about Fido but there is no introduction to Fido. Yes, you
gave the standards references but I think that is not sufficient.
I have a T2TRG draft:
https://datatracker.ietf.org/doc/draft-irtf-t2trg-security-setup-iot-devices/
which has a short description of FIDO which is pretty complicated by itself.

- My second concern is the use of AAA for IoT devices. I mentioned this
before on some other EMU draft.
I believe that AAA will not work with IoT. The way AAA  servers function it
will not be scalable to the billions of IoT devices expected to be deployed.

Behcet


On Mon, Oct 30, 2023 at 9:55 AM Alan DeKok 
wrote:

> On Oct 30, 2023, at 9:53 AM, josh.howl...@gmail.com wrote:
> > This is true, but EAP-FIDO is still not a free lunch:
> > - EAP-FIDO implies the existence of a web-service to perform the initial
> > registration
>
>   Yes.
>
> > - That web-service needs to share state with the RADIUS server
>
>   It is admittedly hard for administrators to talk to each other.  But I
> don't think this is an unreasonable request to make.
>
> > Today's turnkey EAP provisioning solutions are not *conceptually*
> dissimilar
> > to this (often using self-signed CAs with EAP-TLS for mutual authn; and
> LDAP
> > to the Enterprise directory to authz the client cert's SAN). The
> onboarding
> > would just be transparent for an end-user because of the browser/OS/TPM
> > integration (so no "installer" to download and execute).
> >
> > It would be very interesting if the initial registration could be
> performed
> > in-band of EAP (using WebPKI).
>
>   That would be very useful.  It's a balance between making the draft
> useful (large, long delay), or getting it done quickly, but perhaps missing
> features.
>
>   I think the ideal approach is for EAP-FIDO to allow:
>
> * authentication via FIDO as discussed
>
> * provisioning of FIDO credentials
>
> * de-provisioning of credentials.
>
>   The last one is hard, as how do you de-provision credentials if you've
> deleted them, and you can't prove who you are?
>
>   Alan DeKok.
>
> ___
> Emu mailing list
> Emu@ietf.org
> https://www.ietf.org/mailman/listinfo/emu
>
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] New I-D: A new EAP method called EAP-FIDO

[Alan DeKok]

On Oct 30, 2023, at 9:53 AM, josh.howl...@gmail.com wrote:
> This is true, but EAP-FIDO is still not a free lunch:
> - EAP-FIDO implies the existence of a web-service to perform the initial
> registration

  Yes.

> - That web-service needs to share state with the RADIUS server

  It is admittedly hard for administrators to talk to each other.  But I don't 
think this is an unreasonable request to make.

> Today's turnkey EAP provisioning solutions are not *conceptually* dissimilar
> to this (often using self-signed CAs with EAP-TLS for mutual authn; and LDAP
> to the Enterprise directory to authz the client cert's SAN). The onboarding
> would just be transparent for an end-user because of the browser/OS/TPM
> integration (so no "installer" to download and execute).
> 
> It would be very interesting if the initial registration could be performed
> in-band of EAP (using WebPKI).

  That would be very useful.  It's a balance between making the draft useful 
(large, long delay), or getting it done quickly, but perhaps missing features.

  I think the ideal approach is for EAP-FIDO to allow:

* authentication via FIDO as discussed

* provisioning of FIDO credentials

* de-provisioning of credentials.

  The last one is hard, as how do you de-provision credentials if you've 
deleted them, and you can't prove who you are?

  Alan DeKok.

___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] New I-D: A new EAP method called EAP-FIDO

[josh.howlett]

>   It's almost 2024, and MDM is still difficult.  There are a large number
of
> companies who are happy to charge recurring monthly fees, per user, for
> MDM solutions.  That's bad for everyone but them.

This is true, but EAP-FIDO is still not a free lunch:
- EAP-FIDO implies the existence of a web-service to perform the initial
registration
- That web-service needs to share state with the RADIUS server

Today's turnkey EAP provisioning solutions are not *conceptually* dissimilar
to this (often using self-signed CAs with EAP-TLS for mutual authn; and LDAP
to the Enterprise directory to authz the client cert's SAN). The onboarding
would just be transparent for an end-user because of the browser/OS/TPM
integration (so no "installer" to download and execute).

It would be very interesting if the initial registration could be performed
in-band of EAP (using WebPKI).

>   We've had ~20+ years of relying on end users to carry the burden of
> supplicant configuration.  That practice is a failure, and should be
replaced
> with something better,

+1

Josh


___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] New I-D: A new EAP method called EAP-FIDO

[Alan DeKok]

On Oct 30, 2023, at 7:20 AM, Hannes Tschofenig  
wrote:
> you cannot complain about the use of TLS in EAP when the EAP method you
> propose relies on TLS. The TLS-based authentication is an essential part
> of the FIDO solution. Without TLS it is completely insecure.

  I don't think that the proposal is to remove TLS, so we can put that concern 
to rest.

> Regarding the benefit of FIDO: I don't think the "main benefit of using
> FIDO is the ease of provisioning a credential to the supplicant". Once
> you have an authenticated channel, it is trivial to provision new
> credentials.

  Unfortunately that hasn't been my experience.  We've had HTTPS and user 
authentication over the web for decades.  Yet that hasn't made it trivial to 
deploy credentials for EAP.

  It's almost 2024, and MDM is still difficult.  There are a large number of 
companies who are happy to charge recurring monthly fees, per user, for MDM 
solutions.  That's bad for everyone but them.

> There are hundreds of protocols that do that. IMHO the
> benefit of FIDO is that you have an installed base of hardware tokens
> that allow you to store these newly minted credentials.

  The benefit I see is that EAP-FIDO can require the use of web CAs for EAP.  
That is largely the practice anyways.  But it's difficult to do, because of the 
previously mentioned difficulty with deploying credentials.

  Having pre-configured credentials means that EAP-FIDO is essentially just 
"use pre-configured web CAs with pre-configured FIDO credentials".  That 
requirement means that EAP-FIDO should be enormously easier to configure than 
previous TLS-based EAP methods.

> 
> On the security front I am wondering whether the introduction of this
> use case weakens the use of FIDO for the web. In the web case, an
> important aspect is to perform authentication and authorization of the
> domain name with which the credentials are later utilized. For network
> access authentication the domain authentication and authorization is, as
> you have been mentioning in the draft and also in your emails, rather
> weak. Have you looked into this aspect? Attacks that result from
> cross-protocol use isn't uncommon.

  We can use the NAI realm here.

  i.e. for the web "I want to authenticate to example.com".

  For EAP. "I want to authenticate to @example.com"

  There is little practical difference between the two.  The main difference is 
things like DNS CAA records.  But those can be checked when the user is online 
(and FIDO is provisioned).  The resulting information can be cached for offline 
use with EAP.

  So EAP-FIDO involves taking pre-existing practices / credentials, and 
describing how supplicant authors can implement the protocol.  The end user 
configuration is then little more than "use FIDO on SSID X, with credentials 
for domain Y".

  That is simple enough that the end user can configure it manually.  And 
critically, cannot configure it *incorrectly*.  It's either secure and it 
works, or it's insecure and it doesn't work.

  We've had ~20+ years of relying on end users to carry the burden of 
supplicant configuration.  That practice is a failure, and should be replaced 
with something better,

  Alan DeKok.

___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] New I-D: A new EAP method called EAP-FIDO

[Hannes Tschofenig]

Hi Jan,


you cannot complain about the use of TLS in EAP when the EAP method you
propose relies on TLS. The TLS-based authentication is an essential part
of the FIDO solution. Without TLS it is completely insecure.


Regarding the key extractor use you describe below: I don't remember
this technique being used by FIDO. I have worked in the FIDO Alliance in
the early days on U2F / UAF but might have missed some more recent
developments.


Regarding the benefit of FIDO: I don't think the "main benefit of using
FIDO is the ease of provisioning a credential to the supplicant". Once
you have an authenticated channel, it is trivial to provision new
credentials. There are hundreds of protocols that do that. IMHO the
benefit of FIDO is that you have an installed base of hardware tokens
that allow you to store these newly minted credentials.


On the security front I am wondering whether the introduction of this
use case weakens the use of FIDO for the web. In the web case, an
important aspect is to perform authentication and authorization of the
domain name with which the credentials are later utilized. For network
access authentication the domain authentication and authorization is, as
you have been mentioning in the draft and also in your emails, rather
weak. Have you looked into this aspect? Attacks that result from
cross-protocol use isn't uncommon.


Ciao

Hannes



Am 24.10.2023 um 12:22 schrieb Jan-Frederik Rieckers:

On 24.10.23 10:58, josh.howl...@gmail.com wrote:

It is good to see this work progressing.

1. I agree with Hannes' observation that it isn't necessary to
premise EAP-FIDO on the claimed weaknesses of other EAP methods.  I
suggest replacing paragraphs 2-5 with content summarising the
proposal. In particular I am surprised that the document doesn't
discuss (what I would consider to be) the main benefit of using FIDO:
the ease of provisioning a credential to the supplicant.


I must confess, the text is mainly driven by my bad experience from my
days as part of the eduroam administration team at the university of
Bremen, and my current experience with a change in the root
certificate for almost every eduroam IdP in Germany, because the
self-operated CA almost every institution used stopped issuing server
certificates and we are now migrating to a new CA provider.


The wording in the draft is a bit harsh, and I sincerely apologize to
everyone that felt offended by that wording, that wasn't my intention.
I'll adjust that for a future version of the draft.


There are several reasons to specify the EAP-TLS certificate
validation the way it is specified, and it works fine if the
configuration is pushed to the clients, i.e. by MDM mechanisms.
The spec leaves all degrees of freedom for server operators, and does
not have any external dependencies, which is great for managed devices.

But the moment you enter the BYOD world, users will get it wrong and
there is no default way that is secure. Admins need to publish the
information about CA and Server Name and need to rely on the user's
ability to configure this correctly. And server operators have no way
of verifying the configuration on client devices, unless they operate
a rogue AP and log which users log in there, to give them a slap on
the wrist.

And the reason that Android for a long time hat "Do not validate" as a
default setting for EAP-TTLS/EAP-PEAP is a symptom of the problem
here: It is much more easy to just disable the security checks than it
is to configure them correctly.


2. I am not persuaded by the two arguments given in section 6.3 for
not reusing existing tunnelled methods.


I'm open to discuss this with an open mind, the first draft is just
the way that I imagined it, if there are reasons to do it another way,
I'm not set on the current spec.


* Misconfiguration of server certificate validation parameters:
perhaps I am missing something, but in terms of the UI can't this be
solved by disabling the parameter options/fields if the EAP-FIDO
inner method is selected?


Definitely this could be done. Maybe I'm just too pessimistic here to
expect that UIs will get it wrong.


* Export of TLS material: I thought this TLS material is often
required by phase 2 of other tunnelled methods? E.g. for validating
cryptobindings.


I don't know exactly what you mean by that?
The current spec uses exported TLS material to generate the FIDO
challenge, so the FIDO-Auth is bound to the TLS tunnel.
One question would be if we can achieve the opoosite, that is: binding
the exported MSPPE-Keys to the FIDO auth too, not just the TLS tunnel.



I think there is an argument that defining EAP-FIDO as a method that
could be used within PEAP, TTLS and TEAP could drive adoption.

3. I have unsure about tying this specification so tightly to the
WebPKI. There is a tremendous convenience in using the WebPKI for
validating the server certificate, but the WebPKI is not a
well-defined concept. In practice, it is the bucket of CAs that my OS
vendor preinstalls 

Re: [Emu] New I-D: A new EAP method called EAP-FIDO

[Dan Harkins]

On 10/25/23 8:31 AM, Michael Richardson wrote:

As a goal, we need to migrate to more use of EAP-TLS in home environments.
RCM requires it in the end.


  The problem with EAP-TLS is certificate enrollment and trust which we
still have not solved in a way that would work for Joe and Sally Sixpack
running their home network. (Note: I'm assuming that Joe and Sally would
not be running a RADIUS/EAP server in their house but somehow the AP
would be terminating the EAP-TLS transaction).

  RCM means that MAC addresses can't be relied upon anymore; good. The
solution is not EAP-TLS in the home though, it's getting away from the
"single passphrase per SSID" model that Wi-Fi came up with 20+ years ago
and still cannot move beyond. For the record, it's possible to send a
password identifier in the WPA3 exchange to support multiple credentials
on a single SSID (it's part of the 802.11 standard) but the largest mobile
phone company refuses to support it so it's kind of dead-in-the-water.

  So instead of something simple and straightforward like password
identifiers to identify the credential we have shared AD accounts (!) using
MSCHAPv2 (!!) running on a parallel captive portal SSID (!!!) to use a 
broken

and antiquated enrollment protocol () and using some remote logging to
identify who is making the request (!). At some point the increased
complexity and insanity of it all should tell us that what we're doing is
not quite right. But here we are.


  Dan.

--
"The object of life is not to be on the side of the majority, but to
escape finding oneself in the ranks of the insane." -- Marcus Aurelius

___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] New I-D: A new EAP method called EAP-FIDO

[josh.howlett]

>   If you can do an onboarding SSID, there are many simpler things which
can
> be done, too.  e.g. downloading configuration files from a  captive
portal.

Yes, but not with a managed Chromebook... My point being that bootstrapping
EAP configuration provisioning is not just a problem for BYOD.

Steering the conversation back to EAP-FIDO: both it and the captive portal
use WebPKI for provisioning, so there's an equivalence that arguably makes
my handwringing around WebPKI moot. Perhaps it is an acceptable price to pay
for the convenience.



___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] New I-D: A new EAP method called EAP-FIDO

[Alan DeKok]

On Oct 25, 2023, at 1:52 PM, josh.howl...@gmail.com wrote:
> I discovered recently that you can't provision a client cert for EAP-TLS onto 
> a Chromebook using the Google MDM. Instead, you configure the MDM with 
> information that enables the Chromebook to obtain one using SCEP from an 
> Enterprise CA. But the user needs to log into the Chromebook to obtain the 
> certificate over SCEP and, of course, the user can't log in without network 
> access. The "solution" is to stand-up an onboarding SSID can reach Google and 
> the SCEP endpoint.

  If you can do an onboarding SSID, there are many simpler things which can be 
done, too.  e.g. downloading configuration files from a  captive portal.

> (The organisation decided to provision the devices with EAP-PEAP/MSCHAPv2 and 
> a shared AD account instead, using RADIUS and Google logs to correlate users 
> to Chromebooks)

  Oh my.

  I can't publicly say what I would like, so I will leave it at that.

  Alan DeKok.

___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] New I-D: A new EAP method called EAP-FIDO

[josh.howlett]

> As a goal, we need to migrate to more use of EAP-TLS in home environments.
 
I discovered recently that you can't provision a client cert for EAP-TLS onto a 
Chromebook using the Google MDM. Instead, you configure the MDM with 
information that enables the Chromebook to obtain one using SCEP from an 
Enterprise CA. But the user needs to log into the Chromebook to obtain the 
certificate over SCEP and, of course, the user can't log in without network 
access. The "solution" is to stand-up an onboarding SSID can reach Google and 
the SCEP endpoint.

(The organisation decided to provision the devices with EAP-PEAP/MSCHAPv2 and a 
shared AD account instead, using RADIUS and Google logs to correlate users to 
Chromebooks)

I'm not bashing EAP-TLS but highlighting that an apparently trivial 
configuration can involve a disproportionate amount of infrastructure and 
complexity...

Josh



___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] New I-D: A new EAP method called EAP-FIDO

[Alan DeKok]

On Oct 25, 2023, at 11:55 AM, Jan-Frederik Rieckers  wrote:
> For the current use case with FIDO keys, I don't know if we had different 
> viewpoints, so I'll just clarify my point: Since FIDO tokens are basically 
> "transferable" between devices (either by pulling the hardware token out and 
> plugging it into a different computer or by some Vendor-magic with software 
> FIDO token to share them between devices of the same person), how do we 
> ensure that the CA pinning is transferred too?
> It is a valid use-case to have a FIDO token for your login and use a 
> different device every time, i.e. a pool of company laptops with standardized 
> logins, but for network access you need a YubiKey and then you can do 
> EAP-FIDO.

  This isn't an issue for web logins.  So we should find some way to ensure 
that it is not an issue for EAP.

> With EAP-FIDO, the amount of configuration needed is significantly reduced, 
> so the user acceptance to type in the last few config options should be 
> there. The bootstrapping will be much easier, especially if the Passkey that 
> should be used with WiFi is already registered with the institution. Then 
> it's really just "Hey Phone, I want to use this WiFi with EAP-FIDO, and my 
> realm is example.com".

  The FIDO exchange does not involve the transfer of any private information, 
unlike EAP methods which use passwords.  This means it doesn't really matter 
which CA is used, or which server certificate is presented.

  i.e. if the user has an NAI of @example.com, then the server should present a 
certificate for "example.com".i.e. SubjectAltName should contain a hostname 
in that realm.  Since we're not doing DNS, the exact host name doesn't matter.

  The server certificate should be signed with a CA known to the supplicant.  
And it doesn't matter which CA.

  I think that the discussion here shows that pinning a server cert or CA cert 
will create more problems than it solves.

  Alan DeKok.

___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] New I-D: A new EAP method called EAP-FIDO

[Eliot Lear]

On 25.10.2023 17:31, Michael Richardson wrote:

As a goal, we need to migrate to more use of EAP-TLS in home environments.


TEAP!



OpenPGP_0x87B66B46D9D27A33.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] New I-D: A new EAP method called EAP-FIDO

[Jan-Frederik Rieckers]

On 25.10.23 17:31, Michael Richardson wrote:

 > Since the credential is not necessarily used on the same device that the 
FIDO
 > credential was registered (example: YubiKeys that are registered by the 
admin
 > and then issued to the user), the information needs to be stored in the
 > registration information somehow. I'm not sure if that is possible and/or
 > manageable.

It seems to me that this can be solved, but I agree that it isn't solved yet.
So we probably need a configuration knob here.
One thing that I know a few people have talked about is having a standard
configuration format for clients.


For general EAP methods - yes, definitely.

For the current use case with FIDO keys, I don't know if we had 
different viewpoints, so I'll just clarify my point: Since FIDO tokens 
are basically "transferable" between devices (either by pulling the 
hardware token out and plugging it into a different computer or by some 
Vendor-magic with software FIDO token to share them between devices of 
the same person), how do we ensure that the CA pinning is transferred too?
It is a valid use-case to have a FIDO token for your login and use a 
different device every time, i.e. a pool of company laptops with 
standardized logins, but for network access you need a YubiKey and then 
you can do EAP-FIDO.




 > But we don't have this in BYOD environments like education institutions.

And probably in fewer and fewer enterprises given BYOD.
As a goal, we need to migrate to more use of EAP-TLS in home environments.
RCM requires it in the end.


I don't think that EAP-TLS (EAP-Type 13) is really a goal we should try 
to move everybody to.
Client certificates expire and we have the bootstrapping problem, which 
is still not solved satisfactorily.
And the current EAP-TLS based methods like TTLS and PEAP have a 
bootstrapping problem that's circumvented by choosing "Do not validate".


If we solve the bootstrapping problem, then we can also provision all 
the security parameters easily.
It's definitely worth the effort to try that, but to actually have a 
reliable and secure way to do that, every device needs to be able to 
understand ONE standardized format. Currently we have a patch-work of 
different file formats or APIs (that may not even have a stable 
definition) and this is the root cause for so many problems in eduroam 
provisioning.


With EAP-FIDO, the amount of configuration needed is significantly 
reduced, so the user acceptance to type in the last few config options 
should be there. The bootstrapping will be much easier, especially if 
the Passkey that should be used with WiFi is already registered with the 
institution. Then it's really just "Hey Phone, I want to use this WiFi 
with EAP-FIDO, and my realm is example.com".




Cheers,
Janfred

--
Herr Jan-Frederik Rieckers
Security, Trust & Identity Services

E-Mail: rieck...@dfn.de | Fon: +49 30884299-339 | Fax: +49 30884299-370
Pronomen: er/sein | Pronouns: he/him
__

DFN - Deutsches Forschungsnetz | German National Research and Education 
Network

Verein zur Förderung eines Deutschen Forschungsnetzes e.V.
Alexanderplatz 1 | 10178 Berlin
www.dfn.de

Vorstand: Prof. Dr. Odej Kao (Vorsitzender) | Dr. Rainer Bockholt | 
Christian Zens

Geschäftsführung: Dr. Christian Grimm | Jochem Pattloch
VR AG Charlottenburg 7729B | USt.-ID. DE 1366/23822


smime.p7s
Description: S/MIME Cryptographic Signature
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] New I-D: A new EAP method called EAP-FIDO

[Michael Richardson]

Jan-Frederik Rieckers  wrote:
> Administrators don't fully understand the EAP methods, and they usually 
don't
> have time to dig into that. They just want it to work.

I agree that we have problems.

> With the suggested way to pin the PKI to the one used to provision the
> credential I see several problems:

> * How to store?

> Since the credential is not necessarily used on the same device that the 
FIDO
> credential was registered (example: YubiKeys that are registered by the 
admin
> and then issued to the user), the information needs to be stored in the
> registration information somehow. I'm not sure if that is possible and/or
> manageable.

It seems to me that this can be solved, but I agree that it isn't solved yet.
So we probably need a configuration knob here.
One thing that I know a few people have talked about is having a standard
configuration format for clients.

> And another question remains: What exactly do I store? "I used WebPKI" or
> "The trust anchor was the ISRG Root X1" or "My cert was issued by
> Let'sEncrypt R3" or "the SHA256-FP of the CA cert that issued the server
> cert was "

I think this is something we should actually answer.

> This is not to say that there aren't use cases out there where CA pinning 
is
> useful and the spec should not forbid that possibility, but I don't want 
to
> specify a protocol, where, 20 years from now, people say "Why do we need 
an
> external configuration tool again to configure the trust parameters?"
> For MDM environments like company wifi, where you have your 
well-maintained
> private CA and (more or less) complete control over your end-devices, CA
> pinning is ok.

+1

> But we don't have this in BYOD environments like education institutions.

And probably in fewer and fewer enterprises given BYOD.
As a goal, we need to migrate to more use of EAP-TLS in home environments.
RCM requires it in the end.

> Because the cert parameters are not implicit from information that the 
user
> is willing to configure (usually username and password), the eduroam folks
> developed a tool that helps with the secure setup of the Wifi. And having
> experienced the First-Level-Support, many people complain about "Why is 
it so
> difficult to get on the wifi at the university, can't you just give me the
> wifi password and everything works like at home? What do I need this app
> for?"

Yeah.  It doesn't need to be so hard.
But, PSK is just not actually secure at home.
It's just that on-path attacks at your home are often not worth the effort.

> And pinning the CA in BYOD environments causes a lot of problems in the
> future, that are likely to wander out of sight and only re-surface -- in
> the best case a short time before, in the worst case at the time -- things
> break and now the admins need to act quickly. And this reaction also 
involves
> the end-users, that need to reconfigure their devices and that's never a 
good
> idea, because the latency of end-user action is immense (esp. if they are 
not
> technically versed)

--
Michael Richardson. o O ( IPv6 IøT consulting )
   Sandelman Software Works Inc, Ottawa and Worldwide


signature.asc
Description: PGP signature
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] New I-D: A new EAP method called EAP-FIDO

[Jan-Frederik Rieckers]

On 24.10.23 19:43, Michael Richardson wrote:


Alan DeKok  wrote:
 > Not explicitly, but implicitly.

 > I think the way out here is to not mandate the use of WebPKI.  Instead,
 > we can just say that the EAP certificate should be issues by the same
 > (or equivalent CA) to the one which was used to provision the initial
 > FIDO credentials.

 > In practice, this means WebPKI most of the time.  :)

Actually, that's a stronger statement anyway.
It means that the choice of CA has essentially been pinned, so you'd not be
vulnerable to attacks like ComonoGate.


I think I actually want to be vulnerable to this kind of attack.
- Wait, bear with me, I have a reason for saying that: -

Some of the operational problems that we currently have, especially in 
the eduroam world:
Administrators don't fully understand the EAP methods, and they usually 
don't have time to dig into that. They just want it to work.
And some don't understand that it is a big deal for the Client if the CA 
changes, since it does not cause problems if they change the web server 
certificate. And when they change it they quickly realize that it works 
again if they choose "Do not validate" on their device, so they advise 
that the users configure their devices this way.


With the suggested way to pin the PKI to the one used to provision the 
credential I see several problems:


* How to store?

Since the credential is not necessarily used on the same device that the 
FIDO credential was registered (example: YubiKeys that are registered by 
the admin and then issued to the user), the information needs to be 
stored in the registration information somehow. I'm not sure if that is 
possible and/or manageable.
And another question remains: What exactly do I store? "I used WebPKI" 
or "The trust anchor was the ISRG Root X1" or "My cert was issued by 
Let'sEncrypt R3" or "the SHA256-FP of the CA cert that issued the server 
cert was "



* How do I change the CA?

Certificates expire. This can be seen as bug, and therefore FIDO has an 
advantage over using client certificates, since FIDO credentials don't 
expire at an arbitrary point in time.
For the server side, the certificates also expire and they need to be 
exchanged regularly.
Now the question is: What type of certificate do I use? Since some OSes 
add the CA used for wifi to their OS-wide trust store, I don't want to 
have a small institution with a part-time admin operating its own CA 
with the CA's private key stored with chmod 777 on a dubiously secured 
web server.
So using a private self-operated CA, where the validity time is 
somewhere in the area of 100 years, is a bad idea.


The alternative: We use a certificate provider from the webPKI. But here 
we have options and if the provider that was active at the time of FIDO 
registration has now decided to increase their prices by factor 20, and 
we want to move to a different CA provider, then we don't want to have 
the factor "is this CA from the same root" to be a decision point that 
narrows our options. But more importantly: The eduroam use case is only 
a tiny thing that is a byproduct of the other PKI use cases (mainly 
Web). So it is unlikely that the decision makers are willing to add a 
zero to the amount of money they spend on PKI, just because we need this 
for this one use case of WiFi login.
So now the admins need to have a certificate roll-over, and with BYOD 
deployments that means: Endlessly chasing after users that have not yet 
reconfigured their device, and some VIP users complaining why the WiFi 
again does not work, because they never had such problems at their home 
wifi.


So the intent is to completely get rid of CA pinning (at least by 
default). It only causes problems, especially for admins that do not do 
the admin task full-time, and there are a lot of those.


This is not to say that there aren't use cases out there where CA 
pinning is useful and the spec should not forbid that possibility, but I 
don't want to specify a protocol, where, 20 years from now, people say 
"Why do we need an external configuration tool again to configure the 
trust parameters?"
For MDM environments like company wifi, where you have your 
well-maintained private CA and (more or less) complete control over your 
end-devices, CA pinning is ok.

But we don't have this in BYOD environments like education institutions.

Because the cert parameters are not implicit from information that the 
user is willing to configure (usually username and password), the 
eduroam folks developed a tool that helps with the secure setup of the 
Wifi. And having experienced the First-Level-Support, many people 
complain about "Why is it so difficult to get on the wifi at the 
university, can't you just give me the wifi password and everything 
works like at home? What do I need this app for?"




So - to quickly summarize it and come back to the ComodoGate attack:
The possibility of a Rogue CA is always there.
For the 

Re: [Emu] New I-D: A new EAP method called EAP-FIDO

[Michael Richardson]

Alan DeKok  wrote:
> Not explicitly, but implicitly.

> I think the way out here is to not mandate the use of WebPKI.  Instead,
> we can just say that the EAP certificate should be issues by the same
> (or equivalent CA) to the one which was used to provision the initial
> FIDO credentials.

> In practice, this means WebPKI most of the time.  :)

Actually, that's a stronger statement anyway.
It means that the choice of CA has essentially been pinned, so you'd not be
vulnerable to attacks like ComonoGate.

--
Michael Richardson. o O ( IPv6 IøT consulting )
   Sandelman Software Works Inc, Ottawa and Worldwide






signature.asc
Description: PGP signature
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] New I-D: A new EAP method called EAP-FIDO

[Alan DeKok]

On Oct 24, 2023, at 11:11 AM,   
wrote:
> That is an interesting idea, but it might be tricky for the supplicant to
> validate because provisioning is performed through a browser? 

  All the supplicant has to know is (a) the FIDO credentials, and (b) the CA 
certs used for FIDO.  These are usually in the web CA store.

  That should just be calls to the relevant APIs.

> Jan-Fred and I have previously discussed the option of provisioning the
> supplicant (through the browser) with a credential for the server at the
> time of initial PIDO provisioning. This was also looking tricky, but I think
> the idea also has merit.

  Shades of TEAP!

  Alan DeKok.

___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] New I-D: A new EAP method called EAP-FIDO

[josh.howlett]

> From: Alan DeKok 
> On Oct 24, 2023, at 8:56 AM, josh.howl...@gmail.com wrote:
> > To be clear, what I mean is whether there is another IETF protocol that
> > *mandates* the use of WebPKI?
> 
>   All of them.
> 
>   Not explicitly, but implicitly.
> 
>   I think the way out here is to not mandate the use of WebPKI.  Instead,
we
> can just say that the EAP certificate should be issues by the same (or
> equivalent CA) to the one which was used to provision the initial FIDO
> credentials.

That is an interesting idea, but it might be tricky for the supplicant to
validate because provisioning is performed through a browser? 

Jan-Fred and I have previously discussed the option of provisioning the
supplicant (through the browser) with a credential for the server at the
time of initial PIDO provisioning. This was also looking tricky, but I think
the idea also has merit.

Josh


___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] New I-D: A new EAP method called EAP-FIDO

[Alan DeKok]

On Oct 24, 2023, at 8:56 AM, josh.howl...@gmail.com wrote:
> To be clear, what I mean is whether there is another IETF protocol that
> *mandates* the use of WebPKI?

  All of them.

  Not explicitly, but implicitly.

  I think the way out here is to not mandate the use of WebPKI.  Instead, we 
can just say that the EAP certificate should be issues by the same (or 
equivalent CA) to the one which was used to provision the initial FIDO 
credentials.

  In practice, this means WebPKI most of the time.  :)

  Alan DeKok.

___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] New I-D: A new EAP method called EAP-FIDO

[Jan-Frederik Rieckers]

On 24.10.23 14:56, josh.howl...@gmail.com wrote:

To be clear, what I mean is whether there is another IETF protocol that
*mandates* the use of WebPKI?


I don't know of any, I'm interested in the definitive answer too.


It definitely has a lot of implications to depend on external parties 
for security-relevant portions of the protocol.


The sentiment for the protocol design was "we have to use WebPKI anyway 
for the registration and there is no other good option", but to actually 
publish an RFC with that dependency, the implications should be discussed.



Cheers,
Janfred

--
Herr Jan-Frederik Rieckers
Security, Trust & Identity Services

E-Mail: rieck...@dfn.de | Fon: +49 30884299-339 | Fax: +49 30884299-370
Pronomen: er/sein | Pronouns: he/him
__

DFN - Deutsches Forschungsnetz | German National Research and Education 
Network

Verein zur Förderung eines Deutschen Forschungsnetzes e.V.
Alexanderplatz 1 | 10178 Berlin
www.dfn.de

Vorstand: Prof. Dr. Odej Kao (Vorsitzender) | Dr. Rainer Bockholt | 
Christian Zens

Geschäftsführung: Dr. Christian Grimm | Jochem Pattloch
VR AG Charlottenburg 7729B | USt.-ID. DE 1366/23822


smime.p7s
Description: S/MIME Cryptographic Signature
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] New I-D: A new EAP method called EAP-FIDO

[josh.howlett]

> >   So I see this as two new methods:
> >
> > 1) tunnelled FIDO - for use in TTLS, PEAP, or other TLS-based EAP
methods.
> >
> > 2) TLS-based method with tunnelled FIDO - it can make new / stronger
> > requirements on CA validation, server identity, etc.
> 
> So (2) would be the moral equivalent of (1) inside an existing tunnelled
> method where WebPKI is mandated for server cert validation?
> 
> I have worked with organisations who run AD Certificate Services for the
sole
> purpose of issuing a single server certificate for their NPS cluster, so I
am very
> much in favour of making server certificate validation simpler.
> However, I think we need to be very circumspect about out-sourcing that to
> the WebPKI. Is there another IETF protocol that does this?

To be clear, what I mean is whether there is another IETF protocol that
*mandates* the use of WebPKI?


___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] New I-D: A new EAP method called EAP-FIDO

[josh.howlett]

>   So I see this as two new methods:
> 
> 1) tunnelled FIDO - for use in TTLS, PEAP, or other TLS-based EAP methods.
> 
> 2) TLS-based method with tunnelled FIDO - it can make new / stronger
> requirements on CA validation, server identity, etc.

So (2) would be the moral equivalent of (1) inside an existing tunnelled
method where WebPKI is mandated for server cert validation?

I have worked with organisations who run AD Certificate Services for the
sole purpose of issuing a single server certificate for their NPS cluster,
so I am very much in favour of making server certificate validation simpler.
However, I think we need to be very circumspect about out-sourcing that to
the WebPKI. Is there another IETF protocol that does this?

Josh


___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] New I-D: A new EAP method called EAP-FIDO

[Alan DeKok]

On Oct 24, 2023, at 6:22 AM, Jan-Frederik Rieckers  wrote:
> I must confess, the text is mainly driven by my bad experience from my days 
> as part of the eduroam administration team at the university of Bremen, and 
> my current experience with a change in the root certificate for almost every 
> eduroam IdP in Germany, because the self-operated CA almost every institution 
> used stopped issuing server certificates and we are now migrating to a new CA 
> provider.

  Configuring CAs is hard.  Configuring a CA for each application is harder.  
Starting up a new public CA just for one protocol is impossible.

  The reality is that outside of private CAs, the phrase "CA" is equivalent to 
"web CA".  The web CA certificates are used for pretty much every protocol: 
SMTP, XMPP, Jabber, etc.  We might as well use them for EAP, too.

> There are several reasons to specify the EAP-TLS certificate validation the 
> way it is specified, and it works fine if the configuration is pushed to the 
> clients, i.e. by MDM mechanisms.
> The spec leaves all degrees of freedom for server operators, and does not 
> have any external dependencies, which is great for managed devices.

  We can say that the default is to use web CAs.  But nothing prevents one 
particular site from using a private CA for its domain.  Both uses should be 
explained and permitted.

> And the reason that Android for a long time hat "Do not validate" as a 
> default setting for EAP-TTLS/EAP-PEAP is a symptom of the problem here: It is 
> much more easy to just disable the security checks than it is to configure 
> them correctly.

  Agreed.  The solution here is to require secure behavior through better 
protocol design.

>> 2. I am not persuaded by the two arguments given in section 6.3 for not 
>> reusing existing tunnelled methods.
> 
> I'm open to discuss this with an open mind, the first draft is just the way 
> that I imagined it, if there are reasons to do it another way, I'm not set on 
> the current spec.

  I think defining a new TLS-based method is needed.  For the simple reason 
that we need to require that the default CAs for this method are the web CAs.  
We can't add that requirement to TTLS / PEAP.

>> * Export of TLS material: I thought this TLS material is often required by 
>> phase 2 of other tunnelled methods? E.g. for validating cryptobindings.
> 
> I don't know exactly what you mean by that?
> The current spec uses exported TLS material to generate the FIDO challenge, 
> so the FIDO-Auth is bound to the TLS tunnel.

  This is already done for TTLS:  
https://datatracker.ietf.org/doc/html/rfc5281#section-11.2.2

  A "tunnelled FIDO" method could define something similar for the FIDO 
challenges.

  The tunnelled FIDO method would still need to define how the server 
certificate was validated, and strongly tie the server identity to the FIDO 
process.  But that's just text to be added to a TTLS / PEAP section.

> One question would be if we can achieve the opoosite, that is: binding the 
> exported MSPPE-Keys to the FIDO auth too, not just the TLS tunnel.

  That can be done.  For similar calculations, see TEAP.  It isn't trivial, but 
it's possible.  
https://datatracker.ietf.org/doc/html/draft-ietf-emu-rfc7170bis-14#name-intermediate-compound-key-d

  I think this binding is simpler to do for a new TLS-based EAP-FIDO.  It's 
more difficult to do for TTLS, and I suspect it's not needed.

>> I think there is an argument that defining EAP-FIDO as a method that could 
>> be used within PEAP, TTLS and TEAP could drive adoption.
>> 3. I have unsure about tying this specification so tightly to the WebPKI. 
>> There is a tremendous convenience in using the WebPKI for validating the 
>> server certificate, but the WebPKI is not a well-defined concept. In 
>> practice, it is the bucket of CAs that my OS vendor preinstalls on my 
>> device. The conflation of protocol design (fixed in code) with operational 
>> choices taken by third-parties (so subject to change) could lead to 
>> unexpected outcomes.
> 
> I agree with your last sentence, we definitely introduce a third party that 
> we cannot control (or even anticipate their actions).
> But the idea here is to build a system where we have a default way of 
> configuration that is somewhat secure, and since we can't really establish a 
> trusted EAP-FIDO CA that every device will trust, leveraging the WebPKI for 
> that is the next best thing.
> And we already need the WebPKI for the FIDO registration process.

  Exactly.

  So I see this as two new methods:

1) tunnelled FIDO - for use in TTLS, PEAP, or other TLS-based EAP methods.

2) TLS-based method with tunnelled FIDO - it can make new / stronger 
requirements on CA validation, server identity, etc.

 We could just ban the use of tunnelled FIDO in TTLS / PEAP.  But I'm not sure 
that's practical.  It's likely safer to just define TTLS + tunnelled FIDO.

  Alan DeKok.

___
Emu mailing 

Re: [Emu] New I-D: A new EAP method called EAP-FIDO

[josh.howlett]

> > 2. I am not persuaded by the two arguments given in section 6.3 for not
> > reusing existing tunnelled methods.
> 
> I'm open to discuss this with an open mind, the first draft is just the
> way that I imagined it, if there are reasons to do it another way, I'm
> not set on the current spec.
> 
> > * Misconfiguration of server certificate validation parameters: perhaps I am
> missing something, but in terms of the UI can't this be solved by disabling 
> the
> parameter options/fields if the EAP-FIDO inner method is selected?
> 
> Definitely this could be done. Maybe I'm just too pessimistic here to
> expect that UIs will get it wrong.

Ok -- just checking my understanding was correct :)

> > * Export of TLS material: I thought this TLS material is often required by
> phase 2 of other tunnelled methods? E.g. for validating cryptobindings.
> 
> I don't know exactly what you mean by that?
> The current spec uses exported TLS material to generate the FIDO
> challenge, so the FIDO-Auth is bound to the TLS tunnel.

Most tunnel methods bind phases 1 and 2; I don't believe this should be a 
problem.

> One question would be if we can achieve the opoosite, that is: binding
> the exported MSPPE-Keys to the FIDO auth too, not just the TLS tunnel.

What would be the goal for this?

> > 3. I have unsure about tying this specification so tightly to the WebPKI. 
> > There
> is a tremendous convenience in using the WebPKI for validating the server
> certificate, but the WebPKI is not a well-defined concept. In practice, it is 
> the
> bucket of CAs that my OS vendor preinstalls on my device. The conflation of
> protocol design (fixed in code) with operational choices taken by 
> third-parties
> (so subject to change) could lead to unexpected outcomes.
> 
> I agree with your last sentence, we definitely introduce a third party
> that we cannot control (or even anticipate their actions).
> But the idea here is to build a system where we have a default way of
> configuration that is somewhat secure, and since we can't really
> establish a trusted EAP-FIDO CA that every device will trust, leveraging
> the WebPKI for that is the next best thing.

When you say "default", would this permit other user-provisioned trust anchors 
as well?

Josh


___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] New I-D: A new EAP method called EAP-FIDO

[Eliot Lear]

Ahah!  Ok.  I suggest a slight rename: FIDO's got tokens and Fido's got 
FDO, and the two are quite separate.  EAP-FIDO-TOKEN?


Eliot

On 24.10.2023 12:24, Jan-Frederik Rieckers wrote:

On 24.10.23 09:12, Eliot Lear wrote:> Thanks for the draft.  Question:


Is the intent that the FDO authentication happen each and every time, 
or just during ownership transfer?


The intent is to do a FIDO authentication every time (maybe with the 
exception of TLS session resumption, Text for that is still TODO).


But with CTAP v2 you can trigger silent authentication, so the user 
does not need to touch their FIDO token every time they need to 
re-authenticate, the token just needs to be available (which is more 
complex with hardware tokens like YubiKeys, but very easy with 
OS-backed FIDO implementations)


Cheers,
Janfred


___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu


OpenPGP_0x87B66B46D9D27A33.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] New I-D: A new EAP method called EAP-FIDO

[Jan-Frederik Rieckers]

On 24.10.23 09:12, Eliot Lear wrote:> Thanks for the draft.  Question:


Is the intent that the FDO authentication happen each and every time, or 
just during ownership transfer?


The intent is to do a FIDO authentication every time (maybe with the 
exception of TLS session resumption, Text for that is still TODO).


But with CTAP v2 you can trigger silent authentication, so the user does 
not need to touch their FIDO token every time they need to 
re-authenticate, the token just needs to be available (which is more 
complex with hardware tokens like YubiKeys, but very easy with OS-backed 
FIDO implementations)


Cheers,
Janfred

--
Herr Jan-Frederik Rieckers
Security, Trust & Identity Services

E-Mail: rieck...@dfn.de | Fon: +49 30884299-339 | Fax: +49 30884299-370
Pronomen: er/sein | Pronouns: he/him
__

DFN - Deutsches Forschungsnetz | German National Research and Education 
Network

Verein zur Förderung eines Deutschen Forschungsnetzes e.V.
Alexanderplatz 1 | 10178 Berlin
www.dfn.de

Vorstand: Prof. Dr. Odej Kao (Vorsitzender) | Dr. Rainer Bockholt | 
Christian Zens

Geschäftsführung: Dr. Christian Grimm | Jochem Pattloch
VR AG Charlottenburg 7729B | USt.-ID. DE 1366/23822


smime.p7s
Description: S/MIME Cryptographic Signature
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] New I-D: A new EAP method called EAP-FIDO

[Jan-Frederik Rieckers]

On 24.10.23 10:58, josh.howl...@gmail.com wrote:

It is good to see this work progressing.

1. I agree with Hannes' observation that it isn't necessary to premise EAP-FIDO 
on the claimed weaknesses of other EAP methods.  I suggest replacing paragraphs 
2-5 with content summarising the proposal. In particular I am surprised that 
the document doesn't discuss (what I would consider to be) the main benefit of 
using FIDO: the ease of provisioning a credential to the supplicant.


I must confess, the text is mainly driven by my bad experience from my 
days as part of the eduroam administration team at the university of 
Bremen, and my current experience with a change in the root certificate 
for almost every eduroam IdP in Germany, because the self-operated CA 
almost every institution used stopped issuing server certificates and we 
are now migrating to a new CA provider.



The wording in the draft is a bit harsh, and I sincerely apologize to 
everyone that felt offended by that wording, that wasn't my intention. 
I'll adjust that for a future version of the draft.



There are several reasons to specify the EAP-TLS certificate validation 
the way it is specified, and it works fine if the configuration is 
pushed to the clients, i.e. by MDM mechanisms.
The spec leaves all degrees of freedom for server operators, and does 
not have any external dependencies, which is great for managed devices.


But the moment you enter the BYOD world, users will get it wrong and 
there is no default way that is secure. Admins need to publish the 
information about CA and Server Name and need to rely on the user's 
ability to configure this correctly. And server operators have no way of 
verifying the configuration on client devices, unless they operate a 
rogue AP and log which users log in there, to give them a slap on the wrist.


And the reason that Android for a long time hat "Do not validate" as a 
default setting for EAP-TTLS/EAP-PEAP is a symptom of the problem here: 
It is much more easy to just disable the security checks than it is to 
configure them correctly.



2. I am not persuaded by the two arguments given in section 6.3 for not reusing 
existing tunnelled methods.


I'm open to discuss this with an open mind, the first draft is just the 
way that I imagined it, if there are reasons to do it another way, I'm 
not set on the current spec.



* Misconfiguration of server certificate validation parameters: perhaps I am 
missing something, but in terms of the UI can't this be solved by disabling the 
parameter options/fields if the EAP-FIDO inner method is selected?


Definitely this could be done. Maybe I'm just too pessimistic here to 
expect that UIs will get it wrong.



* Export of TLS material: I thought this TLS material is often required by 
phase 2 of other tunnelled methods? E.g. for validating cryptobindings.


I don't know exactly what you mean by that?
The current spec uses exported TLS material to generate the FIDO 
challenge, so the FIDO-Auth is bound to the TLS tunnel.
One question would be if we can achieve the opoosite, that is: binding 
the exported MSPPE-Keys to the FIDO auth too, not just the TLS tunnel.




I think there is an argument that defining EAP-FIDO as a method that could be 
used within PEAP, TTLS and TEAP could drive adoption.

3. I have unsure about tying this specification so tightly to the WebPKI. There 
is a tremendous convenience in using the WebPKI for validating the server 
certificate, but the WebPKI is not a well-defined concept. In practice, it is 
the bucket of CAs that my OS vendor preinstalls on my device. The conflation of 
protocol design (fixed in code) with operational choices taken by third-parties 
(so subject to change) could lead to unexpected outcomes.


I agree with your last sentence, we definitely introduce a third party 
that we cannot control (or even anticipate their actions).
But the idea here is to build a system where we have a default way of 
configuration that is somewhat secure, and since we can't really 
establish a trusted EAP-FIDO CA that every device will trust, leveraging 
the WebPKI for that is the next best thing.

And we already need the WebPKI for the FIDO registration process.

Janfred

--
Herr Jan-Frederik Rieckers
Security, Trust & Identity Services

E-Mail: rieck...@dfn.de | Fon: +49 30884299-339 | Fax: +49 30884299-370
Pronomen: er/sein | Pronouns: he/him
__

DFN - Deutsches Forschungsnetz | German National Research and Education 
Network

Verein zur Förderung eines Deutschen Forschungsnetzes e.V.
Alexanderplatz 1 | 10178 Berlin
www.dfn.de

Vorstand: Prof. Dr. Odej Kao (Vorsitzender) | Dr. Rainer Bockholt | 
Christian Zens

Geschäftsführung: Dr. Christian Grimm | Jochem Pattloch
VR AG Charlottenburg 7729B | USt.-ID. DE 1366/23822


smime.p7s
Description: S/MIME Cryptographic Signature
___
Emu mailing list

Re: [Emu] New I-D: A new EAP method called EAP-FIDO

[josh.howlett]

Hi Jan-Fred,

It is good to see this work progressing.

1. I agree with Hannes' observation that it isn't necessary to premise EAP-FIDO 
on the claimed weaknesses of other EAP methods.  I suggest replacing paragraphs 
2-5 with content summarising the proposal. In particular I am surprised that 
the document doesn't discuss (what I would consider to be) the main benefit of 
using FIDO: the ease of provisioning a credential to the supplicant.

2. I am not persuaded by the two arguments given in section 6.3 for not reusing 
existing tunnelled methods.

* Misconfiguration of server certificate validation parameters: perhaps I am 
missing something, but in terms of the UI can't this be solved by disabling the 
parameter options/fields if the EAP-FIDO inner method is selected? 

* Export of TLS material: I thought this TLS material is often required by 
phase 2 of other tunnelled methods? E.g. for validating cryptobindings.

I think there is an argument that defining EAP-FIDO as a method that could be 
used within PEAP, TTLS and TEAP could drive adoption.

3. I have unsure about tying this specification so tightly to the WebPKI. There 
is a tremendous convenience in using the WebPKI for validating the server 
certificate, but the WebPKI is not a well-defined concept. In practice, it is 
the bucket of CAs that my OS vendor preinstalls on my device. The conflation of 
protocol design (fixed in code) with operational choices taken by third-parties 
(so subject to change) could lead to unexpected outcomes.

Josh

> -Original Message-
> From: Emu  On Behalf Of Jan-Frederik Rieckers
> Sent: Monday, October 23, 2023 11:38 PM
> To: emu@ietf.org
> Subject: [Emu] New I-D: A new EAP method called EAP-FIDO
> 
> Hi emu folks,
> 
> as already teased at the last IETF, we finally have a first I-D ready for EAP-
> FIDO.[1]
> 
> The basic idea:
> Password-based network authentication is not really state-of-the-art any
> more and, due to failure to verify the server certificate, sometimes even
> completely broken.
> Almost every device nowadays has a TPM chip or something similar, that is
> able to speak FIDO, either with the help of the OS or generically.
> So, why not use FIDO to log in to networks?
> 
> There is a proof-of-concept implementation (not compatible with the spec in
> the draft yet, just to show that "It works™") that was used to perform an
> eduroam login at a conference with an EAP-FIDO key.
> 
> We will hold a side-meeting on Monday evening, 18:00 in Room Karlin 4, to
> discuss some of the open design questions and to gather feedback on what
> else may be needed in the specification.
> 
> We have also requested a time slot at the emu session on Tuesday, to shortly
> present the work.
> 
> Any feedback is welcome.
> 
> Cheers
> Janfred
> 
> [1]: https://datatracker.ietf.org/doc/draft-janfred-eap-fido/
> 
> --
> Herr Jan-Frederik Rieckers
> Security, Trust & Identity Services
> 
> E-Mail: rieck...@dfn.de | Fon: +49 30884299-339 | Fax: +49 30884299-370
> Pronomen: er/sein | Pronouns: he/him
> ___
> ___
> 
> DFN - Deutsches Forschungsnetz | German National Research and Education
> Network Verein zur Förderung eines Deutschen Forschungsnetzes e.V.
> Alexanderplatz 1 | 10178 Berlin
> www.dfn.de
> 
> Vorstand: Prof. Dr. Odej Kao (Vorsitzender) | Dr. Rainer Bockholt | Christian
> Zens
> Geschäftsführung: Dr. Christian Grimm | Jochem Pattloch VR AG
> Charlottenburg 7729B | USt.-ID. DE 1366/23822

___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] New I-D: A new EAP method called EAP-FIDO

[Eliot Lear]

Hi Jan-Frederik

Thanks for the draft.  Question:

Is the intent that the FDO authentication happen each and every time, or 
just during ownership transfer?


Thanks,

eliot

On 24.10.2023 00:38, Jan-Frederik Rieckers wrote:

Hi emu folks,

as already teased at the last IETF, we finally have a first I-D ready 
for EAP-FIDO.[1]


The basic idea:
Password-based network authentication is not really state-of-the-art 
any more and, due to failure to verify the server certificate, 
sometimes even completely broken.
Almost every device nowadays has a TPM chip or something similar, that 
is able to speak FIDO, either with the help of the OS or generically.

So, why not use FIDO to log in to networks?

There is a proof-of-concept implementation (not compatible with the 
spec in the draft yet, just to show that "It works™") that was used to 
perform an eduroam login at a conference with an EAP-FIDO key.


We will hold a side-meeting on Monday evening, 18:00 in Room Karlin 4, 
to discuss some of the open design questions and to gather feedback on 
what else may be needed in the specification.


We have also requested a time slot at the emu session on Tuesday, to 
shortly present the work.


Any feedback is welcome.

Cheers
Janfred

[1]: https://datatracker.ietf.org/doc/draft-janfred-eap-fido/


___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu


___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] New I-D: A new EAP method called EAP-FIDO

[hannes.tschofenig]

Hi Jan,

I would like to learn a bit more about the concerns you expressed regarding 
EAP-TLS.
If there are problems, then they should have been fixed with the work on 
EAP-TLS 1.3.

You write:
"
   The specification for EAP-TLS [RFC5216] does not
   include guidance on how to decide if a certificate is valid for this
   specific authentication.
"

What does it mean when you say "... valid for this specific authentication"?
Which certificate? Client or Server certificate?

"
   supplicant has no implicit information to determine the expected
   subject name in the server's certificate
"

https://datatracker.ietf.org/doc/html/rfc5216#section-5.2 has something to say 
about this topic and RFC 9190 didn't change it.
This does not fit your needs, as it seems. Why?

Note that you can define a new EAP method without having to dismiss other EAP 
methods.
Standardizing EAP-FIDO is just fine. Hence, I would re-write the intro to say 
something about FIDO authentication. 

Ciao
Hannes

-Original Message-
From: Emu  On Behalf Of Jan-Frederik Rieckers
Sent: Dienstag, 24. Oktober 2023 00:38
To: emu@ietf.org
Subject: [Emu] New I-D: A new EAP method called EAP-FIDO

Hi emu folks,

as already teased at the last IETF, we finally have a first I-D ready for 
EAP-FIDO.[1]

The basic idea:
Password-based network authentication is not really state-of-the-art any more 
and, due to failure to verify the server certificate, sometimes even completely 
broken.
Almost every device nowadays has a TPM chip or something similar, that is able 
to speak FIDO, either with the help of the OS or generically.
So, why not use FIDO to log in to networks?

There is a proof-of-concept implementation (not compatible with the spec in the 
draft yet, just to show that "It works™") that was used to perform an eduroam 
login at a conference with an EAP-FIDO key.

We will hold a side-meeting on Monday evening, 18:00 in Room Karlin 4, to 
discuss some of the open design questions and to gather feedback on what else 
may be needed in the specification.

We have also requested a time slot at the emu session on Tuesday, to shortly 
present the work.

Any feedback is welcome.

Cheers
Janfred

[1]: https://datatracker.ietf.org/doc/draft-janfred-eap-fido/

--
Herr Jan-Frederik Rieckers
Security, Trust & Identity Services

E-Mail: rieck...@dfn.de | Fon: +49 30884299-339 | Fax: +49 30884299-370
Pronomen: er/sein | Pronouns: he/him
__

DFN - Deutsches Forschungsnetz | German National Research and Education Network 
Verein zur Förderung eines Deutschen Forschungsnetzes e.V.
Alexanderplatz 1 | 10178 Berlin
www.dfn.de

Vorstand: Prof. Dr. Odej Kao (Vorsitzender) | Dr. Rainer Bockholt | Christian 
Zens
Geschäftsführung: Dr. Christian Grimm | Jochem Pattloch VR AG Charlottenburg 
7729B | USt.-ID. DE 1366/23822

___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] New I-D: A new EAP method called EAP-FIDO

[Alan DeKok]

  It looks good as a first draft.  Some first draft comments:

  I would suggest that the default should be to using the Web PKI for server 
authentication, unless there's a client configuration which says to use a 
different CA.  This behavior means that configuring EAP-FIDO for a domain is 
simple:

* somehow provision FIDO using public net access

* associate that domain + FIDO + keys + SSID.

  Note that there's no "configure trusted CA" or "configure trusted server 
cert".  We can instead leverage the web PKI.


  The client needs to signal which server it's authenticating to (RPID).
Since EAP-FIDO is likely to be proxied, the only safe choice here is an 
anonymous NAI.  Other choices are possible, but since they can't be proxied, 
they're much less useful.

  This choice means that each SSID can be associated with only one domain, but 
that's an existing limitation so it's not all that terrible.  The requirement 
for EAP packets to be proxied means that the client must supply a domain for 
authentication, which pretty much prevents it from using other domains.

  CBOR wouldn't be my first choice.  But it's 2023, so whatever.

  I like the idea of deprovisioning as part of specification.  Ideally it could 
be driven by either end of the conversation.  i.e. the user should be able to 
say "I don't want to talk to this domain any more", and the authenticator 
should be able to say "I've deleted your user account".

  Deprovisioning user credentials could be part of a non-EAP FIDO process, too. 
 But there definitely needs to be a way to deprovision the *EAP* configuration 
portion.

> On Oct 23, 2023, at 6:38 PM, Jan-Frederik Rieckers  wrote:
> 
> Hi emu folks,
> 
> as already teased at the last IETF, we finally have a first I-D ready for 
> EAP-FIDO.[1]
> 
> The basic idea:
> Password-based network authentication is not really state-of-the-art any more 
> and, due to failure to verify the server certificate, sometimes even 
> completely broken.
> Almost every device nowadays has a TPM chip or something similar, that is 
> able to speak FIDO, either with the help of the OS or generically.
> So, why not use FIDO to log in to networks?
> 
> There is a proof-of-concept implementation (not compatible with the spec in 
> the draft yet, just to show that "It works™") that was used to perform an 
> eduroam login at a conference with an EAP-FIDO key.
> 
> We will hold a side-meeting on Monday evening, 18:00 in Room Karlin 4, to 
> discuss some of the open design questions and to gather feedback on what else 
> may be needed in the specification.
> 
> We have also requested a time slot at the emu session on Tuesday, to shortly 
> present the work.
> 
> Any feedback is welcome.
> 
> Cheers
> Janfred
> 
> [1]: https://datatracker.ietf.org/doc/draft-janfred-eap-fido/
> 
> -- 
> Herr Jan-Frederik Rieckers
> Security, Trust & Identity Services
> 
> E-Mail: rieck...@dfn.de | Fon: +49 30884299-339 | Fax: +49 30884299-370
> Pronomen: er/sein | Pronouns: he/him
> __
> 
> DFN - Deutsches Forschungsnetz | German National Research and Education 
> Network
> Verein zur Förderung eines Deutschen Forschungsnetzes e.V.
> Alexanderplatz 1 | 10178 Berlin
> www.dfn.de
> 
> Vorstand: Prof. Dr. Odej Kao (Vorsitzender) | Dr. Rainer Bockholt | Christian 
> Zens
> Geschäftsführung: Dr. Christian Grimm | Jochem Pattloch
> VR AG Charlottenburg 7729B | USt.-ID. DE 1366/23822
> ___
> Emu mailing list
> Emu@ietf.org
> https://www.ietf.org/mailman/listinfo/emu

___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

[Emu] New I-D: A new EAP method called EAP-FIDO

[Jan-Frederik Rieckers]

Hi emu folks,

as already teased at the last IETF, we finally have a first I-D ready 
for EAP-FIDO.[1]


The basic idea:
Password-based network authentication is not really state-of-the-art any 
more and, due to failure to verify the server certificate, sometimes 
even completely broken.
Almost every device nowadays has a TPM chip or something similar, that 
is able to speak FIDO, either with the help of the OS or generically.

So, why not use FIDO to log in to networks?

There is a proof-of-concept implementation (not compatible with the spec 
in the draft yet, just to show that "It works™") that was used to 
perform an eduroam login at a conference with an EAP-FIDO key.


We will hold a side-meeting on Monday evening, 18:00 in Room Karlin 4, 
to discuss some of the open design questions and to gather feedback on 
what else may be needed in the specification.


We have also requested a time slot at the emu session on Tuesday, to 
shortly present the work.


Any feedback is welcome.

Cheers
Janfred

[1]: https://datatracker.ietf.org/doc/draft-janfred-eap-fido/

--
Herr Jan-Frederik Rieckers
Security, Trust & Identity Services

E-Mail: rieck...@dfn.de | Fon: +49 30884299-339 | Fax: +49 30884299-370
Pronomen: er/sein | Pronouns: he/him
__

DFN - Deutsches Forschungsnetz | German National Research and Education 
Network

Verein zur Förderung eines Deutschen Forschungsnetzes e.V.
Alexanderplatz 1 | 10178 Berlin
www.dfn.de

Vorstand: Prof. Dr. Odej Kao (Vorsitzender) | Dr. Rainer Bockholt | 
Christian Zens

Geschäftsführung: Dr. Christian Grimm | Jochem Pattloch
VR AG Charlottenburg 7729B | USt.-ID. DE 1366/23822


smime.p7s
Description: S/MIME Cryptographic Signature
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu