Re: [Emu] Adoption call for eap.arpa
On 12.03.24 13:45, Alexander Clouter wrote: On Tue, 12 Mar 2024, at 12:37, Yanlei(Ray) wrote: My understanding here is that the EAP server and client will not authenticate each other in EAP-TLS, and all the authentication will be done in the " captive portal ". So why recommend EAP-TLS as a provisioning method? Just send the identifier "por...@eap.arpa" and then jump to a " captive portal ". Is that OK? So for OOB provisioning (ie. get an IP to access a captive portal) the conversation would be: EAP-Identity Request <<< EAP-Identity Response[por...@eap.arpa] EAP-Success Sounds sensible. I don't think it's that straight forward. For Enterprise-WiFi we still need cryptographic keys for the WiFi 4-way handshake, so establishing a TLS-Tunnel is needed to derive the WPA keys. 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 https://www.dfn.de Vorstand: Prof. Dr.-Ing. Stefan Wesner | Prof. Dr. Helmut Reiser | Christian Zens Geschäftsführung: Dr. Christian Grimm | Jochem Pattloch VR AG Charlottenburg 7729B | USt.-ID. DE 136623822 smime.p7s Description: S/MIME Cryptographic Signature ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Adoption call for eap.arpa
I think this work is useful, emu is the right WG for that, so I'm in favor of adopting. Cheers, Janfred On 07.03.24 23:38, Peter Yee wrote: This is an adoption call for the eap.arpa Internet-Draft (draft-dekok-emu-eap-arpa). This is an ancillary draft that Alan DeKok briefed during the Prague (IETF 118) meeting. Seeing as it primarily exists as a forward-looking extraction of certain descriptive material and IAB .arpa domanrequests from other EMU documents, we consider it within the scope of the WG charter. Alan did a recent minor update to the document and will speak briefly about it during IETF 119. With that said, your WG chairs would appreciate hearing your feedback on whether this document is adopted or not. While it's not critical to adopt, it really simplifies the domain registration for things like TLS-POK and would have been great back when we did EAP-NOOB. We are particularly interested in hearing from parties who are willing to review the specification. So, if you've got interest in seeing the work adopted, please formalize that by responding to the EMU mailing list with your position. The deadline for feedback is March 21st. Yes, that's during IETF 119 but after the EMU time slot, so hopefully you will have formed an opinion by then, if not sooner. We hope to hear from lots of you! Joe and Peter 1) https://datatracker.ietf.org/doc/draft-dekok-emu-eap-arpa/ -- 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 https://www.dfn.de Vorstand: Prof. Dr.-Ing. Stefan Wesner | Prof. Dr. Helmut Reiser | Christian Zens Geschäftsführung: Dr. Christian Grimm | Jochem Pattloch VR AG Charlottenburg 7729B | USt.-ID. DE 136623822 smime.p7s Description: S/MIME Cryptographic Signature ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] New Version Notification for draft-janfred-eap-fido-02.txt
On 05.03.24 13:40, Alan DeKok wrote: On Mar 5, 2024, at 5:46 AM, Jan-Frederik Rieckers wrote: Well, the beauty of CBOR is that it is very easily extendable. I completely agree that, with the limited list of map keys, using CBOR instead of TLVs seems like shooting cannons at mosquitos, but if in the future we want to do more with this, we can. Extensibility also has its downsides. If we're not sure we need the functionality, then *unused* functionality is ripe for exploits or issues. Definitely, and I'm keeping that in mind. (thanks for explicitly pointing it out though) I think there are examples of both. Standards that are too restrictive, where people had to misuse some protocol aspects to extend it (or it just never reached a noticeable deployment stage, because elements were missing and they couldn't extend it without breaking compatibility), and too open standards where the extensibility itself was misused and a target vector for attacks. I hope we can find some middle ground where everyone is happy about the limitations and the extensibility. Resource exhaustion is a problem in CBOR, as it is in any other serialization/deserialization solution. If we only need 3 pieces of data, none nested, then CBOR has more issues than TLVs, due to it's inherent nesting. i.e. the temptation for implementors is to pass the raw CBOR data to a CBOR library. Which means nested structures, complex maps, etc. And none of that will be used by EAP-FIDO. For now I'd suggest concentrating on getting the crypto right, and the request / response exchange. Data encoding can always be changed before it's widely implemented. +1 The current CBOR message format is actually for me too a reminder of what data needs to be sent when and by whom, this won't change if we switch to TLVs or use base64url-encoded XML for transmission. (/sarcasm hint: ok, the XML is maybe a bit too extreme) They also limit the length of a CBOR message, with a recommendation that every authenticator MUST support at least messages of 1024 bytes and that platforms have to respect the max message length signaled by the authenticator. So EAP-FIDO would also need to negotiate / signal message length? Not necessarily. The negotiation between Authenticator and platforn in FIDO/CTAP is done because the authenticators possibly have very limited capabilities, so they need to negotiate that. For EAP-FIDO I think it would be reasonable to just go with the 16k limit for TLS record (if I remember correctly this is the limit for one TLS record) We could say something similar about the allowed depth and length of the CBOR messages sent in EAP-FIDO. Is that fixed, or negotiated? If we stay with CBOR, I would just have that depth fixed in the specification. I think it is reasonable to have a limit on there. And if some extension in the future wants to have a deeper CBOR structure, there is always the possibility to encode the data as byte sequence, so implementations that don't understand this can just skip it, but implementations which do understand it can send any data they want. 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 https://www.dfn.de Vorstand: Prof. Dr.-Ing. Stefan Wesner | Prof. Dr. Helmut Reiser | Christian Zens Geschäftsführung: Dr. Christian Grimm | Jochem Pattloch VR AG Charlottenburg 7729B | USt.-ID. DE 136623822 smime.p7s Description: S/MIME Cryptographic Signature ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] New Version Notification for draft-janfred-eap-fido-02.txt
On 05.03.24 10:33, Heikki Vatiainen wrote: On Tue, 5 Mar 2024 at 09:56, Alexander Clouter <mailto:alex%2bi...@coremem.com>> wrote: Using an entire serialiser to support only a map carrying attributes with 1->3 *predetermined* keys seems a bit of a cannon to deal with a mosquito solution as they go. As a hypothetical, would people have a stronger opinion here if CBOR was swapped for protocol buffers or ASN.1 in the document? Ok, I'll bite. I've worked recently with ASN.1 (hello GSM world) and found it much easier to work than I initially though. I found the interoperability of different MAP and TCAP (again GSM) implementations to work well together. In other words, the software I made successfully talked to other software from the beginning. This allowed the work to concentrate on the software functionality instead of serialising bits on the line. I'd say the main point is: use encoding that's appropriate for the task. ASN.1 suits for 2G/3G complex things. Simple TLVs have so far worked well with EAP. I haven't worked with CBOR, but I'd be interested to know if, for example, how careful we need to be with serialiser/deserialiser to avoid problems similar to exponential expansions attacks [1], etc. TLVs are known for people working on Radius/Diameter/EAP. With CBOR it would be useful if the draft were to have information to avoid potential problems, especially if the CBOR input can come from untrusted sources. I'm sure this information is available, and it would help the implementers if they're notified about what to look out for, if needed. [1] https://en.wikipedia.org/wiki/Billion_laughs_attack <https://en.wikipedia.org/wiki/Billion_laughs_attack> Well, the beauty of CBOR is that it is very easily extendable. I completely agree that, with the limited list of map keys, using CBOR instead of TLVs seems like shooting cannons at mosquitos, but if in the future we want to do more with this, we can. Resource exhaustion is a problem in CBOR, as it is in any other serialization/deserialization solution. Here a quote from the CTAP2 spec regarding the use of CBOR in CTAP2 and how they deal with the problem: https://fidoalliance.org/specs/fido-v2.0-ps-20190130/fido-client-to-authenticator-protocol-v2.0-ps-20190130.html#message-encoding Because some authenticators are memory constrained, the depth of nested CBOR structures used by all message encodings is limited to at most four (4) levels of any combination of CBOR maps and/or CBOR arrays. Authenticators MUST support at least 4 levels of CBOR nesting. Clients, platforms, and servers MUST NOT use more than 4 levels of CBOR nesting. They also limit the length of a CBOR message, with a recommendation that every authenticator MUST support at least messages of 1024 bytes and that platforms have to respect the max message length signaled by the authenticator. We could say something similar about the allowed depth and length of the CBOR messages sent in EAP-FIDO. One thing that I still have to look into is how we would deal with multiple Discoverable Credentials registered for the same RPID, one solution would be to send a signature from all of them, and at least then I would put the tuple (Credential ID, authdata, signature) in a CBOR map, and have the possibility to put multiple of these maps in the message. I'll try to get some Face2Face time with some CBOR experts and talk to them about the way they would suggest using CBOR in this protocol. 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 https://www.dfn.de Vorstand: Prof. Dr.-Ing. Stefan Wesner | Prof. Dr. Helmut Reiser | Christian Zens Geschäftsführung: Dr. Christian Grimm | Jochem Pattloch VR AG Charlottenburg 7729B | USt.-ID. DE 136623822 smime.p7s Description: S/MIME Cryptographic Signature ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] New Version Notification for draft-janfred-eap-fido-02.txt
Hi, here the answer to the questions regarding PKIDs: On 04.03.24 11:06, Alexander Clouter wrote: Why not just *always* send the list of PKIDs? How is this list formed by a server *before* it knows the user identity? Is a possible that the anon identify from Phase 1 is enough to perform this? The list is formed by the server AFTER querying for the user's identity. Taking a step back: For the FIDO authentication, we have two authentication options: (I always use "PKID" in this mail, the FIDO terminology uses "Credential ID" and "Public Key Credential source", but for the server, both are just arbitrary strings that uniquely identify a public key, I still have to read the FIDO specs in full to decide which of these terms I should use in the final document) Option 1: Discoverable Credentials. The client knows the RelyingParty ID and has a credential stored for that RPID. It can simply sign the request, and includes both the signature and the PKID used for the signature in the answer. The server recognizes the user by the PKID the client sends, and can look up the public key for that particular PKID and then verify the signature. Option 2: Server-Side Credentials. The client knows the RelyingParty ID, but has no discoverable credentials, so it needs additional information. The client sends its username to the server, and only now the server has enough information to compile the list of PKIDs. This is just a simple "SELECT PKID from USER_DB where USER=''" The server simply looks up all PKIDs that is has stored for this user. (Theoretically, the server could compile this list earlier if the client sent its real identity in the anonymous identity, but we shouldn't even make that a possibility, some vendor will think "hey, that's a great idea, let's ignore that this is supposed to be an ANONYMOUS identity and fill in our real identity". (Just a random thought, not that this happened before) The PKIDs are the "containers" with which the FIDO Authenticator can reconstruct the private key that was generated during registration and can sign the request with that private key. Since every PKID is bound to one specific FIDO Authenticator and with non-discoverable credentials, the Authenticator does not store state locally, there is no way of determining the PKID in any other way than having the server send a list over. I hope that made it clearer. As you asked for some resources (not sure whether they are suitable as bedtime-stories though *grin* ) https://www.w3.org/TR/webauthn/ has a lot of good definitions and descriptions on how certain things work, I'd suggest looking at these terms specifically: * "Credential ID" * "Discoverable Credential" * "Server-side Credential" I am trying to reconcile these two descriptions and the closest I can get is it seems in practice PKIDs can only be offered by the server after seeing the identity? By introducing EAP Identity an implementer would be more easily able to proxy the inner FIDO authentication but the downside of this is it would bring in an extra round trip as the server still has to send after the EAP Identity response "now do FIDO" and the client cannot initiate this. On a related note, as a passing thought though I am not sure how this could work, opportunistically could the client make use of the SubjectAltName from the outer TLS jacket of Phase 1 to infer a suitable PKID and avoid needing to make an 'information' round trip? If the server side thinks the peer has picked incorrectly, that is when it responses with the list of PKIDs as it now also knows the peer's identity. 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 https://www.dfn.de Vorstand: Prof. Dr.-Ing. Stefan Wesner | Prof. Dr. Helmut Reiser | Christian Zens Geschäftsführung: Dr. Christian Grimm | Jochem Pattloch VR AG Charlottenburg 7729B | USt.-ID. DE 136623822 smime.p7s Description: S/MIME Cryptographic Signature ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] New Version Notification for draft-janfred-eap-fido-02.txt
I am a grumpy old fart and love my TLV's, maybe others share this opinion...about TLVs, not me of course! :) To be honest, I hate TLV, especially with fixed-length types. Either you waste resources by defining a 2 byte or 4 byte type field, or you run into resource exhaustion if your type field was too small. I don't expect that we would run into a problem with that with this specification soon, even with extensions, but why risk it? (I'm not fixed on using CBOR for the message format, but since CTAP2 also uses CBOR at least the client needs to have a CBOR library anyway.) I haven't understood CBOR Tags fully yet, if we can reach the same goal with tags instead of maps, I'm all for it. Myself, I would fold 'PKID' into 'PKIDs' and make it a 'list of length one' when used, but really this is a matter of personal taste. Again, I like to be explicit. If we have an attribute that says "MUST be of length one", some vendor will ignore it, on the sending or receiving side. How do we deal with two PKIDs? do we take the first one? The last one? Do we abort completely? I find it better to be explicit, this way we avoid such errors in implementation from the get-go. 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 https://www.dfn.de Vorstand: Prof. Dr.-Ing. Stefan Wesner | Prof. Dr. Helmut Reiser | Christian Zens Geschäftsführung: Dr. Christian Grimm | Jochem Pattloch VR AG Charlottenburg 7729B | USt.-ID. DE 136623822 smime.p7s Description: S/MIME Cryptographic Signature ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] New Version Notification for draft-janfred-eap-fido-02.txt
Thanks so much for the comments. I'll respond to some from the top of my head, the others I'll address some time next week. On 03.03.24 13:39, Alexander Clouter wrote: Section 4.1.2 - It just popped up as an idea in my reply to the the SEC review of TEAP but... EAP-TLS sub-methods have been copying the version bits since forever. Maybe it is time to break the mold? You could instead mark the version field just as reserved bits and move to use TLS ALPN to indicate version as it solves all the problems of downgrade attacks. It would though require a registration for the entry. Fortunately, this is the initial version, so you could just use "no ALPN" as the indicator and make it a problem for 'future you' to seek a registration when you want a v2. The idea here is that future versions may signal some information outside the TLS tunnel. Our first idea, where this kind of still stems from was that the server signals the RPID outside the TLS tunnel, so the client can verify that the server's certificate is in fact valid for that. Now that we've moved the RPID to be an explicit configuration item, this has become obsolete, but who knows what other things you could signal there. But I'm open to just define those as "reserved" and completely rely on ALPN. Section 4.3 --- Explicitly stating SHA256 is going to get you into trouble as hardcoding these things makes it awkward to remove them later (eg. MD5 and RADIUS) Instead I would be inclined to mix your client component (the 'second' part) by using it as the 'context' value for the TLS-Exporter. If you look at the exporter (RFC8446, section 7.5) it is used to mix the label which I suspect is what you are looking for; not part of the secret which the client part is likely to be public knowledge. This way, as future ciphers and TLS versions come along, you should not need to update the 'hardcoded' SHA256 as you have just outsourced the problem to the TLS-Exporter; the OpenSSL magic for this is `SSL_CIPHER_get_handshake_digest(SSL_get_current_cipher(ssl))`. The idea to use SHA256 comes from FIDO, they make a lot of use of SHA-256. But of course, since that part is not done inside the FIDO Authenticator, there should be no problem to use the hash algorithm negotiated in the cipher suite for that too. Thanks for spotting that. Section 6.1.1: -- Do not mix the advantages and disadvantages into the same itemised list. Completely agree. That's still on my TODO list to reformat that. Shame on me for not doing that this time around, I'll definitely fix that in the -03 version of the draft. Cheers, Janfred smime.p7s Description: S/MIME Cryptographic Signature ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] New Version Notification for draft-janfred-eap-fido-02.txt
Hi emu folks, I just posted a new version of the EAP-FIDO draft. We had some discussion on the name "EAP-FIDO" at the last IETF and we have come up with some name options since, but none of them resonate with me yet. I have started a pad with different name options, everyone is invited to chime in: https://md.kif.rocks/VcVOg34pSFWh64Ev_JsG6Q For the changes from the previous version: There was some rewording in several paragraphs, I've added some text around error handling. The most prominent change from the previous draft version is that we now propose that, in the standard usecase, the user only configures the Relying Party ID and that the server certificate is then valid for "eap-fido-authentication." (or something similar, depending on the final name for the protocol). I am planning to work on an implementation during the hackathon to have a better understanding and can identify possible missing spec and the different error conditions that we need to signal. I will be presenting my progress at the emu session in Brisbane. Comments are welcome, as always. See you in Brisbane, Janfred On 01.03.24 21:34, internet-dra...@ietf.org wrote: A new version of Internet-Draft draft-janfred-eap-fido-02.txt has been successfully submitted by Jan-Frederik Rieckers and posted to the IETF repository. Name: draft-janfred-eap-fido Revision: 02 Title:EAP-FIDO Date: 2024-03-01 Group:Individual Submission Pages:36 URL: https://www.ietf.org/archive/id/draft-janfred-eap-fido-02.txt Status: https://datatracker.ietf.org/doc/draft-janfred-eap-fido/ HTML: https://www.ietf.org/archive/id/draft-janfred-eap-fido-02.html HTMLized: https://datatracker.ietf.org/doc/html/draft-janfred-eap-fido Diff: https://author-tools.ietf.org/iddiff?url2=draft-janfred-eap-fido-02 Abstract: This document specifies an EAP method leveraging FIDO2 keys for authentication in EAP. About This Document This note is to be removed before publishing as an RFC. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-janfred-eap-fido/. Discussion of this document takes place on the EAP Method Update Working Group mailing list (mailto:emu@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/emu/. Subscribe at https://www.ietf.org/mailman/listinfo/emu/. The IETF Secretariat -- 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 https://www.dfn.de Vorstand: Prof. Dr.-Ing. Stefan Wesner | Prof. Dr. Helmut Reiser | Christian Zens Geschäftsführung: Dr. Christian Grimm | Jochem Pattloch VR AG Charlottenburg 7729B | USt.-ID. DE 136623822 smime.p7s Description: S/MIME Cryptographic Signature ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
[Emu] New version of draft-janfred-eap-fido-01
Hi to all, I just posted an update for the EAP-FIDO draft that primarily contains updates to the terminology and a bit of a rewording in the introduction. Following the discussion in Prague, I've started a list of possible names to replace the (too) generic "EAP-FIDO" as name of the protocol. If you have ideas on names (or comments on the existing proposals) feel free to add them to the pad: https://md.kif.rocks/VcVOg34pSFWh64Ev_JsG6Q?both We will continue to work on the draft. One big remaining TODO is the decision on the configuration options. We will hopefully have a new draft version that includes that too towards the end of the year. 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
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/ <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
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
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
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
e 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 webPKI, the CA/B forum mandates mechanisms to at least detect such rogue behavior and the affected CA won't be in trust stores much longer. In my opinion, the danger of having a dubious private CA is much higher. 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) --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 -- 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
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
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
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 Sign
[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 smime.p7s Description: S/MIME Cryptographic Signature ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
[Emu] Nits found in draft-ietf-emu-rfc7170bis-03
Hi all, I have read section 1-3 of the current version of the RFC7170bis draft and found a few nits: Section 2.1: and handles the iapplication data Section 3.2: TLS-PSK may work (or not) with TEAP, depending on the status of a particular implementation, and it therefore not useful to deploy it. ^^ missing 'is' (or replace it with is) Section 3.5: [...] using the tls- unique [...] remove the space here. Session-Id = teap_type \| tls-unique ^^ should probably only be "|" Section 3.6.3: If there is a non-fatal error handling the inner method, instead [...] ^^^ I had to read the whole sentence twice to understand that it means "If there is a (non-fatal error) (handling the inner methdo)" (Brackets indicate words belonging together) Maybe this sentence could be adjusted (i.e. exchanging "handling" by "processing" or inserting a word like "while handling" or "in handling") Section 3.7: The link to Section 4.3 on the datatracker is a link to section 4.3 of the draft, not to RFC3748, as it was intended. Section 3.8: Server authentication results if the peer trusts [...] ^^^ Maybe use a different word here? (Same thing a few sentence further.) mutual authentication and an Master Session Key (MSK) ^^ *a* Master or *an* MSK This whole sentence sounds weird to me and I'm not exactly sure what the text is trying to say there. Section 3.8.1: The TEAP peer operations between obtaining the tls_unique value [...] ^^ Inconsitency: tls-unique everywhere else (happens again in this sentence) Maybe I'll have more nits in a few days, when I had time to read the other sections. Cheers, Janfred -- 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] I-D Action: draft-ietf-emu-bootstrapped-tls-01.txt
Hi to all, In the introduction (Section 1 and and 1.3) the phrase "catch-22" is used twice. I needed to look up the phrase to know what it meant. I'm sure that I am not the only one who does not know the meaning of this phrase, so I suggest the authors reword this so it is clear to everyone what is meant by that, regardless of knowing the respective saying. Suggestion for the second occurrence: ---8<--- Enterprise deployments typically require an [IEEE802.1X]/EAP-based authentication to obtain network access. Protocols like Enrollment over Secure Transport (EST) [RFC7030] can be used to enroll devices into a Certification Authority to allow them to authenticate using 802.1X/EAP. This creates a ~~catch-22~~ **circular dependency** where a certificate is needed for network access and network access is needed to obtain certificate. ---8<--- Something similar could be done for the first paragraph in the introduction. Greetings Janfred On 24.10.22 16:00, internet-dra...@ietf.org wrote: A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the EAP Method Update WG of the IETF. Title : Bootstrapped TLS Authentication Authors : Owen Friel Dan Harkins Filename: draft-ietf-emu-bootstrapped-tls-01.txt Pages : 12 Date: 2022-10-24 Abstract: This document defines a mechanism that enables a bootstrapping device to establish trust and mutually authenticate against a network. Bootstrapping devices have a public private key pair, and this mechanism enables a network server to prove to the device that it knows the public key, and the device to prove to the server that it knows the private key. The mechanism leverages existing DPP and TLS standards and can be used in an EAP exchange. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-emu-bootstrapped-tls/ There is also an htmlized version available at: https://datatracker.ietf.org/doc/html/draft-ietf-emu-bootstrapped-tls-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-emu-bootstrapped-tls-01 Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts -- 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 OpenPGP_0x0D8BA25D24BECA96.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
[Emu] New version of draft-rieckers-emu-eap-ute
Hi, I have just published a new version for my EAP-UTE draft I briefly presented at IETF 113 in Vienna. https://datatracker.ietf.org/doc/draft-rieckers-emu-eap-ute/ EAP-UTE is an EAP method like EAP-NOOB, which relies on an Out-Of-Band message to establish a mutual trust between peer and server. Instead of JSON, EAP-UTE relies on CBOR for message encoding and aims to be extensible to allow for future use cases. For the -00 version, I haven't received any direct feedback, whether this is something the emu-WG would be interested in. Since my presentation I have changed the message format a bit and have a not yet complete but somehow functional proof-of-concept implementation with a custom server and an ESP32 with ESP-IDF as client. I hope to get some feedback for this before IETF 115. My main question is if the basic idea of re-defining EAP-NOOB with a different message flow and message encoding makes sense and would be a possible item for this working group or is this wasted effort? The draft itself still has a lot of TODOs, but if someone is willing to read it and give feedback on the overall protocol design, I'd be grateful for that. Greetings Janfred -- 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] Note taker for IETF 113
Hi, I'd be happy to take notes for all agenda items except the EAP-NOOB/EAP-UTE discussion. Greetings Janfred -- 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] New drafts EAP-NOOB-Observations and EAP-UTE
Hi to all, For a Masters project at the University of Bremen and in my capacity as one of the national roaming operators for eduroam in Germany at the German National Research and Education Network I am currently looking into EAP-NOOB. While reading the then draft, now RFC, for EAP-NOOB I noticed some things about the protocol specification, which I summed up in a draft. https://datatracker.ietf.org/doc/draft-rieckers-emu-eap-noob-observations/ I have not been active in this working group regarding this draft, so I have not followed the discussions about it, maybe some of these observations have already been discussed on the list. I'll look through the archives in the next weeks before the IETF meeting. As part of my studies at the University of Bremen I also tried to put the design principles of EAP-NOOB into a new EAP method "EAP-UTE". In this second draft I am trying to address the observations in the first draft. https://datatracker.ietf.org/doc/draft-rieckers-emu-eap-ute/ The EAP-UTE specification is in a very early stage and has a lot of TODOs/TBDs in the document. I have submitted it anyway, so I could receive feedback. I'll probably modify the editor's copy in the next weeks and maybe even try to have a simple implementation after the hackathon. For now I'm interested in any feedback regarding these two drafts, especially if the new EAP method EAP-UTE is something that I should continue to work on. Greetings Janfred Github links to the drafts: https://github.com/Janfred/draft-rieckers-emu-eap-noob-observations https://github.com/Janfred/draft-rieckers-emu-eap-ute -- 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] Working Group Last Call for TLS-based EAP types and TLS 1.3
Hi to all, I have found some small typos. Section 2.4: > There no "context_value" ([RFC8446] Section 7.5) passed to the TLS- > Exporter function. I suppose an "is" is missing. Section 3: At the end of the 6th paragraph > completely bypass the "inner tunnel" authentication a dot is missing at the end of the sentence. Section 3.1: > with new identies pointing to the new "cloude" change to "cloud" Greetings Janfred -- 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] draft-ietf-emu-eap-tls13-11: OCSP Stapling
Hi to all, as an operator of a EAP-TLS server for eduroam at the University Bremen I just want to give some of my thoughts here, feel free to read or ignore them ;) The eduroam environment is heavily used for BYOD, so we don't have any opportunity to change certificates via a Device Management. Our clients are researchers, employees, students, ... so we can't (and won't) control all devices logging in to our network. We have to use either a private CA (which brings its own problems) or we use a public trust anchor (e.g. T-Telesec with the DFN-Intermediate for most German universities). The deployment is done either manually by the users or with help of tools like eduroam CAT (cat.eduroam.org). I have done some research regarding the revocation of certificates in EAP-TLS and have come to the conclusion that, if a private key gets compromised, we have no possibility to effectively revoke the certificate in a way the clients would notice. This is the result of different problems: * Clients don't support OCSP Stapling The only client platform with default OCSP Stapling enabled in the Client Hello (that I'm aware of) is currently Apple devices. * Servers don't support OCSP Stapling FreeRADIUS 3.0 does not support OCSP Stapling (but FreeRADIUS 4.0 will have support for it) This is probably the software mostly used for eduroam. * Clients don't support the MustStaple Certificate extension I don't have enough knowledge about TLSv1.3 yet, but for <=TLSv1.2 OCSP won't add much security, since the OCSP Stapling is not mandatory. I will look into TLSv1.3 and MustStaple in near future, maybe someone can give me a hint if MustStaple is also active for TLSv1.3? All in all, I definitely think that making OCSP Stapling optional will have a benefit on small devices, but especially for the diverse environment of eduroam, making OCSP Stapling mandatory will increase the overall security of this federation. Maybe it might be a good idea to make OCSP Stapling mandatory for EAP-TLS Servers? Greetings Janfred signature.asc Description: OpenPGP digital signature ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Best practices for supplicants and authenticators
On 18.11.19 16:22, Cappalli, Tim (Aruba) wrote: > So again, if NAIRealm is not bound to an organization’s public domain > name, how does a public CA prove ownership of an NAIRealm? How is this > different than ESSID? It must not be a public domain name, but it can be. Speaking of eduroam this is usually the case, and is also used for roaming. (See RFC7585, the NAPTR DNS record) And if it is, it can be validated by a CA. Janfred signature.asc Description: OpenPGP digital signature ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Idea: New X509 Extension for securing EAP-TLS
There has been some discussion about this idea. I don't have any experience in IETF work yet, so I don't know how this discussion can go on. I would be happy to present my deployment experiences from eduroam and the basic idea in Singapore. (Since I won't attend the meeting in person, I would join from remote) Is there room for that? Jan-Frederik Rieckers signature.asc Description: OpenPGP digital signature ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Idea: New X509 Extension for securing EAP-TLS
On 12.11.19 10:28, Michael Richardson wrote: > You were trying to do a CSR with some extra attributes with a CA (using > ACME? Using LetsEncrypt?) and the CA ignored the things that it couldn't > verify? No, it was a direct request to the CA of our research network. The problem here was, that the CA itself would have had to clarify this with their CA (Telekom Trust Center), because it would mean to set up a new certificate profile. And that wasn't possible for this one usecase. > So, as I understand it, the enrollment process for laptops/phones into > WPA-Enterprise does not include retrieving a set of anchors for that > connection. Or that it is just too hard to do. It works fine if the > devices are compelled by their corporate masters, but this fails for > BYOD, and it fails for cross-realm (which eduroam is). It doesn't. In eduroam this has lead to cat.eduroam.org, where the installers can be downloaded. As Carsten Borman and I already have written in a submission for the IAB DEDR workshop[1], with the need of this tool we also could have used client certificates instead of username/password combinations. For a long time it was easy to connect to eduroam without certificate checking. Especially Android had a very insecure default setting and most of our users just typed in their username and password and connected to eduroam without any certificate check. And if the inner authentication then defaults to PAP an attacker could get many credentials just by setting up a rogue access point in a crowded place. And many universities in Germany use PAP because they don't want a NT-Hashed password in their database. With the expiry of the old Root CA all clients had to change their configuration, because (if set up correctly) the root ca was in fact pinned. We used this rollover to force all our users to use a specific outer identity, to encourage the use of the CAT. Since the expiry we also deny all requests with any other outer identity before the EAP-TLS handshake, to prevent certificate warnings on the user devices. Jan-Frederik --- 1: https://www.iab.org/wp-content/IAB-uploads/2019/05/p16-bormann-wifi.txt signature.asc Description: OpenPGP digital signature ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Idea: New X509 Extension for securing EAP-TLS
On 12.11.19 00:15, Owen Friel (ofriel) wrote: > One deployment consideration is if an operator wants to use a public PKI > (e.g. Lets Encrypt) for their AAA certs, then it could be years, if ever, > before these extensions could be supported (as Alan alludes to), so it would > also be good to define how this could work with standard RFC 6125 DNS-IDs / > RFC 5280 dNSNames. I had a lot of thoughts about this topic. I am experimenting with certificates in EAP-TLS contexts and experienced the problems with getting a certificate with specific extension properties from our public PKI. (In my case a test certificate with a critical MustStaple extension) The Problem with dNSNames is that they are also used in other contexts (mainly HTTPS). There would be the possibility to define a specific prefix to bind it to a Realm without having the certificate being valid for the HTTPS host (e.g. eap-tls.uni-bremen.de for the realm uni-bremen.de) but I don't see the advantage in that. This will probably don't really lead to a change in the supplicants implementations. My deployment experience shows, that the certificate check is the main security problem in WPA2-Enterprise networks. I have seen instructions for installing WPA2-Enterprise networks where they have explicitly suggested switching off the certificate check, probably because it was too complicated for the users and would lead to people complaining at the IT department about the complicated setup. A setup of WPA2-Enterprise can be secure if all devices are part of a centralized Device Management, but especially in eduroam this isn't possible. We have a lot of people who don't really care about security. Jan-Frederik Rieckers signature.asc Description: OpenPGP digital signature ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Idea: New X509 Extension for securing EAP-TLS
Hi, Thank you for your feedback. I was unaware of RFC 7585. I had a brief look on it and it seems that the certificate part could be used for the goal I try to achieve. I'm not quite sure if the naiRealm should be used for validation on supplicants for EAP-TLS. I would assume it would not be a security issue, but I don't have enough experience to be sure about that. The main reason why I submitted this draft is my experience from the deployment of eduroam at University Bremen. With expiry of the used root CA and the needed migration, we have forced all our users to use one specific outer Identity, to be sure the users configure their devices with the eduroam Configuration Assistant Tool (CAT, cat.eduroam.org) instead of a manual configuration, because in our experience manual configured devices almost always lacked configuration for certificate checking. But I just have experience in local deployment, the federation connections are done at higher levels (country research networks), I don't have an insight there. Greetings, Jan-Frederik Rieckers signature.asc Description: OpenPGP digital signature ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
[Emu] Idea: New X509 Extension for securing EAP-TLS
Hi to all, I have submitted a draft for a new X509v3 extension to improve security in EAP environments by including information which is implicitly defined by the communication context in the certificate . This is done e.g. by including the Realm of the username in the certificate, to give clients the opportunity to decide if the certificate can be trusted apart from (user-set) configuration. https://datatracker.ietf.org/doc/draft-rieckers-eapparameterextension/ This is a very early working state. I would be happy to get feedback if this is useful and the draft goes into the right direction. If people are interested I would prepare a short presentation about deployment experiences in the eduroam at the University Bremen, which have lead to this draft, together with the basic idea how to solve these problems. Probably this draft is not one which can or will be adopted by the EMU working group, but I think this is the right group of people for a first feedback. Kind regards Jan-Frederik Rieckers signature.asc Description: OpenPGP digital signature ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
