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

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

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

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

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

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

Re: [Emu] TEAP: PKCS exchange notes

On 28.08.23 20:10, Heikki Vatiainen wrote: Here are some notes that I thought could be useful to sharpen how PKCS exchange is documented. Example exchange C.11. PKCS Exchange shows how certificate provisioning is done with TEAP:

Re: [Emu] I-D Action: draft-ietf-emu-rfc7170bis-13.txt

Hi Heikki Ok, so *I* let it soak for a few days ;-) and I'm comfortable with the wording. Eliot On 27.08.23 16:42, Heikki Vatiainen wrote: On Fri, 25 Aug 2023 at 22:30, Eliot Lear wrote: I agree with the sentiment, but I think it would be good for the words to soak a bit

Re: [Emu] Patch: revert some IMSK derivation changes

Heikki This change looks good.  I want to code it with the PKCS ops to make sure it's okay.  That'll take a little bit. Eliot On 27.08.23 19:16, Heikki Vatiainen wrote: RFC 7170 and the current draft have diverged in how IMSK is calculated. In short: 1. RFC 7170 pass EMSK to TLS-PRF

Re: [Emu] I-D Action: draft-ietf-emu-rfc7170bis-13.txt

I agree with the sentiment, but I think it would be good for the words to soak a bit, since the paragraphs are a little involved. There may be a simpler way to say the same thing. Eliot On 25.08.23 21:27, Alan DeKok wrote: On Aug 25, 2023, at 10:07 AM, Heikki Vatiainen wrote: I have one

Re: [Emu] WGLC on draft-ietf-emu-rfc7170bis-11

https://datatracker.ietf.org/doc/draft-ietf-emu-bootstrapped-tls/ On 19.08.23 21:12, Michael Richardson wrote: Eliot Lear wrote: >> We don't need or want anonymous ciphersuites here. > We should keep the TLS-POK work in mind. I didn't find an obvious draft about that in t

Re: [Emu] WGLC on draft-ietf-emu-rfc7170bis-11

On 18 Aug 2023, at 23:26, Michael Richardson wrote: > > If we are talking about an RFC8995 (BRSKI) mechanism then: > > a) It requires that the Peer defer validation of the Server's certificate > until later on when another signed artifact is received (RFC8366 voucher). > b) The server still

Re: [Emu] I-D Action: draft-ietf-emu-rfc7170bis-12.txt

Just to follow up: On 18.08.23 19:47, Alan DeKok wrote: On Aug 18, 2023, at 1:33 PM, Eliot Lear wrote: The peer SHOULD verify the validity of the EAP server certificate and SHOULD also examine the EAP server name presented in the certificate

Re: [Emu] I-D Action: draft-ietf-emu-rfc7170bis-12.txt

Alan, A few things with this text: I'm having some issues with Section 3.3:     The peer SHOULD verify the validity of the EAP server    certificate and SHOULD also examine the EAP server name presented in       the certificate in order to determine whether

Re: [Emu] WGLC on draft-ietf-emu-rfc7170bis-11

On 18.08.23 15:31, Alan DeKok wrote: I don't see why we would want to_allow_ inner method resumption. What benefit does it bring over just using resumption on the outer TLS session? +1.  What's the use case? Eliot ___ Emu mailing list

Re: [Emu] WGLC on draft-ietf-emu-rfc7170bis-11

I plan to implement. On 17.08.23 21:11, Michael Richardson wrote: wrote: > Alan has issued -11 of draft-ietf-emu-rfc7170bis. He > believes it covers all of the outstanding issues that needed to be > resolved. We held up the WGLC until we could have our session

Re: [Emu] I-D Action: draft-ietf-emu-rfc7170bis-11.txt

I went through -11 and find it entirely editorial in nature with no substantive changes, and entirely unobjectionable. On 14.08.23 16:58, internet-dra...@ietf.org wrote: A New Internet-Draft is available from the on-line Internet-Drafts directories. This Internet-Draft is a work item of the

Re: [Emu] I-D Action: draft-ietf-emu-rfc7170bis-10.txt

I think this is okay.  I'd like to just check the diagrams, but that could happen as part of WGLC. Eliot On 03.08.23 20:34, Alan DeKok wrote: The diff is perhaps more interesting: https://author-tools.ietf.org/iddiff?url1=draft-ietf-emu-rfc7170bis-09=draft-ietf-emu-rfc7170bis-10=--html

Re: [Emu] Housekeeping functionality (Was: Re: I-D Action: draft-ietf-emu-rfc7170bis-09.txt)

Ok, we might be having an Agree-O-thon... On 04.08.23 11:49, Alan DeKok wrote: Access policies are applied after provisioning has been done. So they are entirely irrelevant until the server replies with an EAP Success. Yes.  So COAs and Disconnects aren't necessary at that point.

Re: [Emu] Housekeeping functionality (Was: Re: I-D Action: draft-ietf-emu-rfc7170bis-09.txt)

, Alan DeKok wrote: On Aug 3, 2023, at 4:10 AM, Eliot Lear wrote: I think it's good to consider what's going on on both sides here. At the beginning, both the identity and the role of the device in a network may be unknown, and so a certain access is given. After bootstrapping has occurred

Re: [Emu] Housekeeping functionality (Was: Re: I-D Action: draft-ietf-emu-rfc7170bis-09.txt)

Hi Alan I think it's good to consider what's going on on both sides here.  At the beginning, both the identity and the role of the device in a network may be unknown, and so a certain access is given.  After bootstrapping has occurred (however that happens), then both the role of the device

Re: [Emu] Housekeeping functionality (Was: Re: I-D Action: draft-ietf-emu-rfc7170bis-09.txt)

I don't think this is a substantive change, because what Heikki is raising is entirely a matter of server-side policy.  I also am not sure it's the right change.  For one thing, if a server is willing to issue a new certificate, that's likely a policy statement that everything is AOK.  For

Re: [Emu] I-D Action: draft-ietf-emu-rfc7170bis-09.txt

On 01.08.23 04:02, Alan DeKok wrote: On Jul 31, 2023, at 6:00 PM, Eliot Lear wrote: We're not quite done. The following text needs to be removed, an additional example added: If there is no Phase 2 data, then the EAP server MUST reject the session. There is no reason to have TEAP

Re: [Emu] I-D Action: draft-ietf-emu-rfc7170bis-09.txt

[Sorry- meant to copy the WG] Alan, We're not quite done.  The following text needs to be removed, an additional example added: If there is no Phase 2 data, then the EAP server MUST reject the session. There is no reason to have TEAP devolve to EAP-TLS. IoT devices need a way to

[Emu] Iotdir early review of draft-ietf-ace-wg-coap-eap-08

Reviewer: Eliot Lear Review result: On the Right Track This draft provides a means for EAP authentication via CoAP. This is an evolution on top of EAPoL/EAP so as to not require 802.1X on certain classes of devices. The general goal of reusing existing EAP methods – and code – is admirable. I

Re: [Emu] RFC 7170 bis

On 03.07.23 19:08, Alan DeKok wrote: On Jun 27, 2023, at 7:04 PM, Joseph Salowey wrote: We are nearing completion of RFC7170bis. There are a few open issues in github - https://github.com/emu-wg/rfc7170bis/issues Issue 21 - links to the errata to verify that they have been addressed in

Re: [Emu] RFC 7170 bis

On 28.06.23 01:04, Joseph Salowey wrote: We are nearing completion of RFC7170bis.   There are a few open issues in github - https://github.com/emu-wg/rfc7170bis/issues Issue 21 - links to the errata to verify that they have been addressed in

Re: [Emu] RFC 7170 bis

Hi Joe, I've sent a set of diagrams to Alan for inclusion.  They are the following: * An example flow in which request action is used to ask the client to renew a certificate. * An example error flow of the above * An example flow where only the TLS authentication is required. Eliot On

[Emu] other things

I think I owe a second PR on handling request action TLVs, and I may have found a small inconsistency that we should at least discuss.  See next message. Eliot On 04.04.23 16:59, Alan DeKok wrote: On Mar 30, 2023, at 1:06 PM, Eliot Lear wrote: This is one of two PRs I said I would deliver

[Emu] CSR Attributes TLV and associated text now in PR#6

Hi everyone, This is one of two PRs I said I would deliver.  There is now text for CSR attributes in TEAP.[1]  As we discussed in the WG meeting, I have linked that work to the LAMPS draft on CSR Attributes.  The text essentially leverages RFC 7030 with one modification- there is no need to

Re: [Emu] Working group Last Call for RFC 7170bis

On 25.03.23 14:28, Alexander Clouter wrote: On Sat, 25 Mar 2023, at 12:03, Eliot Lear wrote: I ask that as you consider this thread, you think beyond Basic-Auth to the PKCS operations. I definitely am not qualified to think on this, I would be a fool to not yield to those using those

Re: [Emu] Working group Last Call for RFC 7170bis

I ask that as you consider this thread, you think beyond Basic-Auth to the PKCS operations.  Those are becoming really important to our base. Eliot On 25.03.23 09:52, Alexander Clouter wrote: On Sat, 25 Mar 2023, at 01:08, Heikki Vatiainen wrote: If you are using eapol_test prior to a

Re: [Emu] CSR Attributes (Re: Working group Last Call for RFC 7170bis)

On 13.03.23 07:58, Eliot Lear wrote: On 10.03.23 18:54, Alexander Clouter wrote: On Fri, 10 Mar 2023, at 16:17, Eliot Lear wrote: In Section 4.2.9, the beginning text reads: The Request-Action TLV MAY be sent by both the peer and the server in response to a successful or failed Result TLV

Re: [Emu] CSR Attributes (Re: Working group Last Call for RFC 7170bis)

On 10.03.23 18:54, Alexander Clouter wrote: On Fri, 10 Mar 2023, at 16:17, Eliot Lear wrote: In Section 4.2.9, the beginning text reads: The Request-Action TLV MAY be sent by both the peer and the server in response to a successful or failed Result TLV. I believe this text is overly

[Emu] Add CSR Attributes TLV(Was: Re: Working group Last Call for RFC 7170bis)

This is the second issue that I'd like to address: As discussed early in the development of this document, TEAP currently doesn't support a CSR Attributes TLV.  I propose that it be added, and that its form be the same used in EST (RFC 7030 and draft-ietf-lamps-rfc7030-csrattrs-01) Section

Re: [Emu] request-action (Re: Working group Last Call for RFC 7170bis)

I'm sorry- the subject is wrong.  The IMCK derivation IS clear. This is related solely to Request-Action (doh!). On 10.03.23 17:17, Eliot Lear wrote: Hi Joe, First and foremost, I'd like to again thank Alan for taking this on. Second, because I expect to have a few comments, to keep them

[Emu] IMCK derivation for PKCS ops still not clear (Re: Working group Last Call for RFC 7170bis)

Hi Joe, First and foremost, I'd like to again thank Alan for taking this on. Second, because I expect to have a few comments, to keep them separate, I'll start different threads. In Section 4.2.9, the beginning text reads: The Request-Action TLV MAY be sent by both the peer and the server

Re: [Emu] RFC7170bis and lack of identities

On 04.02.23 08:57, Alexander Clouter wrote: I agree on both points, Result TLV should be final and is easy to explain to others. It may be easy, but I don't think it's quite right. To me, the way to look at this is that when a Result TLV is transmitted by the server, it is a signal that

Re: [Emu] Request-Action Frame only in response to successful or failed Result-TLV?

Sorry- I misread this text.  But I think the text still needs changing for the reasons given below. Eliot On 02.02.23 08:26, Eliot Lear wrote: Section 4.2.9 reads:    The Request-Action TLV MAY be sent by both the peer and the server in    response to a successful or failed Result TLV. I

[Emu] Request-Action Frame only in response to failed Result-TLV?

Section 4.2.9 reads:    The Request-Action TLV MAY be sent by both the peer and the server in    response to a successful or failed Result TLV. I suggest that this text be changed to allow a Request-Action TLV to be sent at any time.  The reasoning for this is that even with a successful

Re: [Emu] RFC7170bis and lack of identities

I am wondering if we should close this issue.  At the end of the day, if the client knows it's doing something like 2FA that requires an EAP method, *it* can initiate.  If it doesn't and the server decides it needs it based on the Basic-Password-Auth-Resp, then the server can insist, using a

Re: [Emu] draft-ietf-emu-rfc7170bis-03.txt and password length

Hiya, On 27.01.23 12:17, Heikki Vatiainen wrote: For example, an OTP system could do this: - Start authentication with username + static password; if ok then - Server prompts for the next method: Choose 1 for push to mobile app, 2 for telephone callback, 3 for emergency use pre-printed code.

Re: [Emu] draft-ietf-emu-rfc7170bis-03.txt and password length

In thinking about this flow, the real issue boils down to this: If the user is going to use 2FA, then the peer needs to know in advance.  If the peer tries to use Basic Auth and server won't accept it, it should simply produce an error.  That's the simplifying flow. If the peer doesn't know

Re: [Emu] draft-ietf-emu-rfc7170bis-03.txt and password length

First, I agree that this is a nit. On 25.01.23 14:54, Alan DeKok wrote: On Jan 25, 2023, at 8:27 AM, Eliot Lear wrote: No negotiation required. It gets the username as part of basic auth, sees the name and then makes a decision to initiate a new inner method. It has to finish

Re: [Emu] draft-ietf-emu-rfc7170bis-03.txt and password length

On 25.01.23 14:22, Alan DeKok wrote: What I'm not clear on is how they would negotiate a special username which triggers a new auth, but without doing a password check. That seems odd to me. No negotiation required.  It gets the username as part of basic auth, sees the name and then

Re: [Emu] draft-ietf-emu-rfc7170bis-03.txt and password length

On 25.01.23 09:21, John Mattsson wrote: That sounds good. Would be good to have text stating that passwords of length 255 characters (the current max) shall be allowed. Requiring a minimum length of 8 or a least 6 characters would be good. If you want to add some implementation guidance I

Re: [Emu] I-D Action: draft-ietf-emu-rfc7170bis-02.txt

On 09.01.23 23:36, Alan DeKok wrote: How about: The order in TLVs are encoded in a TEAP packet does not matter, however there is an order in which TLVs must be processed: 1. Crypto-Binding-TLV 2. Intermediate-Result-TLV 3. Result-TLV 4. Identity-Type TLV 5. EAP-Payload

[Emu] Meta Issue (Re: I-D Action: draft-ietf-emu-rfc7170bis-02.txt)

My suggestion is that this draft not be moved to WGLC until we have working code in hostap for it.  Even better if FR and ISE also match and can test against MSFT. Eliot On 09.01.23 08:43, Alexander Clouter wrote: On Thu, 5 Jan 2023, at 20:13, internet-dra...@ietf.org wrote: Title

[Emu] RFC 7170bis Issue 4: do we want to keep PAC/PAC-Ackonwledgment?

We have discussed not adding a lot into TEAP, but it might be good to consider removing some stuff. PAC tops the list of things I'd like to see removed.  This is relevant to Erratum 5844 in that the example given contains a PAC/PAC-Acknowledgment.  This also, has bearing on whether or not we

[Emu] RFC 7170bis: More small potatoes: use Obsoletes

This document is a complete specification, and as such should obsolete RFC 7170 (if approved). Eliot ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu

[Emu] RFC 7170bis: Small potatoes: IANA registry

This is almost editorial. The TLV registry and the various registrations should now be pointed to *this* document as the authority rather than RFC 7170, and we should retain the registration policy statement for TLVs here. Frankly, specification required is just a little thin. We probably

Re: [Emu] TEAP erratum 5775

Hi Alexander, On 03.01.23 14:40, Alexander Clouter wrote: On Tue, 3 Jan 2023, at 08:20, Eliot Lear wrote: My use case is IOT.  I'm interested in two states: * Nominal: everything looks very similar to EAP-TLS. * Exceptional: a new certificate or a new trust anchor or something else

Re: [Emu] TEAP erratum 5775

Hi Alexander! Zooming down: On 02.01.23 12:10, Alexander Clouter wrote: Fewer conditionals/branching points in implementations? At the moment the rule is "start with S-IMCK[0]" and then both:  * mix in MSK goodness and track that progression  * mix in EMSK goodness and track that progression

Re: [Emu] Adoption call for RFC 7170bis

Hi Alan, On 22.12.22 23:45, Alan DeKok wrote: So I'd like to know what would be in TEAPv2, and what issues there would be if we just documented TEAPv1 "as implemented". I don't see TEAPv2 as much more than functioning TEAPv1.  But if there are people out there who have a functioning

Re: [Emu] Adoption call for RFC 7170bis

Alan, I view this differently.  First, we don't have good deployment numbers for TEAP.   If we bump the version and nobody is using TEAP, then nobody will care.  If we don't bump the version and people ARE using TEAP, we'll get to hear from everyone who cares! From a code standpoint, I

[Emu] TEAP erratum 5844: intermediate response TLV for basic authentication?

This erratum can be found at https://www.rfc-editor.org/errata_search.php?rfc=7170=5844. I propose that this erratum be verified as written.  For a newer version of TEAP we might want to review this. Eliot ___ Emu mailing list Emu@ietf.org

[Emu] TEAP erratum 5775

Hi, I am reviewing the errata on GitHub and would like to close on them.  The first one I am addressing is 5775, which can be found on the RFC Editor page at https://www.rfc-editor.org/errata/eid5775.  Joe's proposed fix can be viewed at

Re: [Emu] [EXTERNAL] Re: More TEAP issues

No, but I would ask that we still have an interim to close the errata. Eliot On 01.12.22 06:22, Joseph Salowey wrote: It sounds like we are gaining consensus to create a revision of TEAP.  The emphasis would be (in priority order): * Aligning specification with current implementations *

Re: [Emu] More TEAP issues

I'd support a revision as well.  See below: On 30.11.22 02:14, Joseph Salowey wrote: [Joe] speaking as a participant, I'd be happy to assist with a revision.  I think it is needed.  Most of the current errata are tracked here - https://github.com/emu-wg/teap-errata/pulls. I think the target

Re: [Emu] TEAP time again: Result and Intermediate and crypto binding TLVs with no inner EAP methods

On 07.10.22 22:46, Alan DeKok wrote: On Oct 5, 2022, at 12:44 PM, Eliot Lear wrote: DR need clarity on how crypto-binding TLVs when there is no inner EAP method. Also note the use of request-action. Key questions: what value to pass for EMSK and MSK in crypto binding response when

[Emu] TEAP no EAP: which "error" for EAP methods that are not available?

DR what to do when peer doesn't want to do an inner EAP method, but you still want to allow peer on the network?  My answer: intermediate-result TLV with status=failure. One potential use case is when you have some devices that support individual users and some that do not.  In this case, the

Re: [Emu] TEAP time again: Result and Intermediate and crypto binding TLVs with no inner EAP methods

There seems to have been a bad edit on my previous message on the 2nd flow.  See below. On 05.10.22 18:42, Eliot Lear wrote: Hi everyone, Picking up on some TEAP work again. DR need clarity on how crypto-binding TLVs when there is no inner EAP method.  Also note the use of request-action

[Emu] TEAP time again: Result and Intermediate and crypto binding TLVs with no inner EAP methods

Hi everyone, Picking up on some TEAP work again. DR need clarity on how crypto-binding TLVs when there is no inner EAP method.  Also note the use of request-action. Key questions: what value to pass for EMSK and MSK in crypto binding response when there is no inner method?  Zeros? Also,

Re: [Emu] Adoption call for EAP-DPP

Hi Behcet, On 08.09.22 17:43, Behcet Sarikaya wrote:Hi Peter, Joe, Also the problem that this draft deals with and also Elliott mentioned in his mail, Wi-Fi Easy Connect already solves it. DPP works with wired when L3 connectivity is pre-established. This is covered in Section 2.3.5 in the

Re: [Emu] Adoption call for EAP-DPP

Peter, Let me clarify why I think it's important to adopt this work. The Wifi Alliance has already standardized the public/private key pair as well as other attributes that can be used to securely onboard a device.  They have also standardized the QR code used to represent this information. 

Re: [Emu] Adoption call for EAP-DPP

I agree with Behcet's comments, but otherwise support the work's adoption. Eliot On 17.08.22 23:36, Behcet Sarikaya wrote: Hi Peter, I quickly read this short document and have some comments. In the informative references section, DPP is listed as Device Provisioning Profile while it should

Re: [Emu] EAP Erratum 6154 on RFC 3579:

Submissions Editor (Eliot Lear) wrote: Corrected URLs below: On 01.04.22 06:48, Independent Submissions Editor (Eliot Lear) wrote: Ok. I have edited – but not yet verified – the two errata accordingly. Please see: https://www.rfc-editor.org/errata/eid6154 https://www.rfc-editor.org/errata/eid6259

Re: [Emu] EAP Erratum 6154 on RFC 3579:

Submissions Editor (Eliot Lear) wrote: Corrected URLs below: On 01.04.22 06:48, Independent Submissions Editor (Eliot Lear) wrote: Ok. I have edited – but not yet verified – the two errata accordingly. Please see: https://www.rfc-editor.org/errata/eid6154 https://www.rfc-editor.org/errata/eid6259

Re: [Emu] EAP Erratum 6154 on RFC 3579:

Corrected URLs below: On 01.04.22 06:48, Independent Submissions Editor (Eliot Lear) wrote: Ok. I have edited – but not yet verified – the two errata accordingly.  Please see: https://www.rfc-editor.org/errata/eid6154 https://www.rfc-editor.org/errata/eid6259 Are there any further edits

Re: [Emu] EAP Erratum 6154 on RFC 3579:

Ok. I have edited – but not yet verified – the two errata accordingly.  Please see: https://www.rfc-editor.org/verify_errata_select.php?eid=6154 https://www.rfc-editor.org/verify_errata_select.php?eid=6259 Are there any further edits that are required? Eliot (ISE) On 01.04.22 00:52, Alan

[Emu] EAP Erratum 6154 on RFC 3579:

unless this group advises otherwise. Eliot Lear (ISE) [1] https://www.rfc-editor.org/errata/eid6154 [2] https://www.rfc-editor.org/errata/eid6259 ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] Question for draft-ietf-emu-tls-eap-types-03

1:57 PM, Alan DeKok wrote: On Jul 3, 2021, at 7:47 AM, Eliot Lear wrote: I don't think Tim could be blamed for holding the view that there is a separation between specifications and how they are used. There's good and bad to the practice.  The good is that the spec can be used in ways

Re: [Emu] Question for draft-ietf-emu-tls-eap-types-03

Hi Alan, I don't think Tim could be blamed for holding the view that there is a separation between specifications and how they are used. There's good and bad to the practice.  The good is that the spec can be used in ways that the creators didn't intend, and thus perahsp there are fewer

Re: [Emu] Question for draft-ietf-emu-tls-eap-types-03

Hi Alan, On 01.07.21 15:23, Alan DeKok wrote: TEAP is one solution, but I don't think everyone is going to move to TEAP overnight. It would be nice to have solutions for existing (and deployed) EAP methods. Perhaps I lost the plot, but what do you propose? Eliot OpenPGP_signature

Re: [Emu] Question for draft-ietf-emu-tls-eap-types-03

Hi Alan Slight segue.. On 30.06.21 15:38, Alan DeKok wrote: If the answer is "use TPM", then that doesn't meet peoples existing needs. It will also take many years for it to become standardized, much less ubiquitous. As an example, here's an EAP / TPM paper from 2010:

Re: [Emu] EAP-TLS 1.3 Section 2.2 text

Let this be the biggest argument on this list ;-) > On 17 May 2021, at 14:44, Alan DeKok wrote: > > > This is just a personal preference, but "MUST NOT" is clearer to me than > SHALL NOT. It's also more used, IIRC. signature.asc Description: Message signed with OpenPGP

Re: [Emu] Issue 47 Certificate identity checks

> On 12 Apr 2021, at 18:25, Joseph Salowey > wrote: > >> >> I would agure there that the federation should have it's own CA. > > That’s what I’m thinking. But I could imagine hardcoded devices that make > use of it. That’s all. > > > [Joe] Relying on a burned

Re: [Emu] Issue 47 Certificate identity checks

> On 12 Apr 2021, at 19:54, Alan DeKok wrote: > > On Apr 12, 2021, at 12:22 PM, Joseph Salowey wrote: >> [Joe] without some sort of name matching using certs from a public CA is >> unwise. > > The only other alternative is to "pin" the server cert. Many systems > support this. Perhaps

Re: [Emu] Issue 47 Certificate identity checks

Hi Alan, > On 12 Apr 2021, at 14:52, Alan DeKok wrote: > >>> >>> EAP TLS peer implementations MUST allow for configuration of a unique trust >>> root to validate the server's certificate. >> >> This statement seems independent of the previous one, and may be overly >> broad. Let me give

Re: [Emu] Issue 47 Certificate identity checks

Hi Joe, I’m okay with most of this text except for as follows: > 2. CAs MAY issue certs to EAP Servers that specify the id-kp-eapOverLAN EKU > specified in RFC 3770. The above sentence is unnecessary. Of COURSE CAs can issue certs with that EKU or any other. What I think you mean is this:

Re: [Emu] Consensus call for result indicators in EAP-TLS 1.3

> On 9 Feb 2021, at 09:53, John Mattsson > wrote: > > Michael Richardson wrote: >> is this really 3.5 round trips -> 4.5 round trips, or is it really more like >> that we are >going from perhaps 5.5 round trips to 6.5 round trips (for >> example). > > Another question is if EAP-Success

Re: [Emu] Last Call: (Deprecating TLSv1.0 and TLSv1.1) to Best Current Practice

Hi there IESG I support the intent of this document, and I think the approach to update the various documents listed is the right one. Because of the breadth of documents updated, I wonder if at least some implementation guidance is warranted, in order to assist developers and even perhaps

Re: [Emu] Proposed TEAP Errata Resolution Summary

Joe, Thanks for all your work on this. On the “discuss”es, would you mind giving some time for them at the meeting? Thanks, Eliot > On 1 Nov 2020, at 23:33, Joseph Salowey wrote: > > Below is the summary of the TEAP errata resolutions. The text that will be > sent to the AD is in the

Re: [Emu] Making Security Practical ... was RE: Moving towards less security in 2020 - OCSP

Hi Hannes, My concern is not about implementation. At least for the sake of discussion, let us assume that we can get the code to where it needs to be. The question is more about what happens when an OCSP server is unavailable, either to the client or to the server (stapled or otherwise).

Re: [Emu] Consensus Call on OCSP usage in draft-ietf-emu-eap-tls13-11

cessfully executing (and validating) the OCSP > protocol first (and disconnect if not reachable/invalid/revoked). > > Just my 2 cents. > Worth more. Eliot > Cheers, > Max > > From: Emu mailto:emu-boun...@ietf.org>> on behalf of > Eliot Lear <mailto:

Re: [Emu] Consensus Call on OCSP usage in draft-ietf-emu-eap-tls13-11

Hi Joe, My suggestion is that we add some discussion about what to do in the case of no connectivity to the CA. This will be a not-uncommon occurrence, IMHO, in industrial use cases. Eliot > On 29 Oct 2020, at 17:23, Joseph Salowey > wrote: > > An issue was raised

Re: [Emu] Proposed Resolution to TEAP Errata 5770

Hi, > > [Joe] Yes I think it is fine to say EAP authentication method. I have been > convinced that the spec requires crypto-binding with the basic password > authentication. I'll need to add this in. > Keep in mind that there might not even be basic auth. One case is that one just

Re: [Emu] draft-ietf-emu-eap-tls13-11: OCSP Stapling

[Trimming] > On 26 Oct 2020, at 16:26, Michael Richardson wrote: > > >>> While this degenerate case of Authentication Server + OCSP Signer on the >>> same >>> machine is kinda dumb from a overall security point of view, it's still >>> better than raw public keys. > >> Yes. Let’s think about

Re: [Emu] draft-ietf-emu-eap-tls13-11: OCSP Stapling

> On 26 Oct 2020, at 15:19, Michael Richardson wrote: > > Signed PGP part > > Eliot Lear wrote: >>> The EAP server is expected to frequently request a OCSP response from >>> the OCSP responder (a server typically run by the certificate >>>

Re: [Emu] draft-ietf-emu-eap-tls13-11: OCSP Stapling

Thanks, John. Please see below: > On 26 Oct 2020, at 13:58, John Mattsson > wrote: > > Hi Eliot, > > The EAP server is expected to frequently request a OCSP response from the > OCSP responder (a server typically run by the certificate issuer). The OCSP > response is then added to the

Re: [Emu] draft-ietf-emu-eap-tls13-11: OCSP Stapling

Hi John, My question is one of pragmatics. In an offline industrial environment, what is expected of the server to accomplish the stapling? Especially if the request is nonced. Eliot > On 26 Oct 2020, at 13:08, John Mattsson > wrote: > > Hi, > > When this was discussed in the group, it

Re: [Emu] draft-ietf-emu-eap-tls13-11: OCSP Stapling

So I’m a client and include a certificate status request. The EAP server isn’t talking to the CA at the moment. Does a nonce have to be used? If so… #fail. If not, what prevents a replay? And if the answer is nothing, what is the threat model we are addressing?

Re: [Emu] draft-ietf-emu-eap-tls13-11: OCSP Stapling

+1. How does anyone even do OCSP without having first gotten onto the network? Eliot > On 21 Oct 2020, at 11:02, Hannes Tschofenig wrote: > > Hi all, > > this draft mandates OCSCP stapling (for use with TLS 1.3 in EAP-TLS) and I > believe this is a problem for implementations. This extra

Re: [Emu] [Technical Errata Reported] RFC7170 (6157)

>> ------ >> Type: Technical >> Reported by: Eliot Lear >> >> Section: 4.2.9 >> >> Original Text >> - >> Status >> >> The Status field is one octet. This indicates the res

[Emu] TEAP Update (was: Re: Working Group Call For adoption of draft-aura-eap-noob-08.txt)

Hi Mohit > > The chairs had an email discussion which hadn't concluded. The main > sticking point was that both Joe and I prefer TEAP being addressed in a > separate update document that fixes all other TEAP errata as well. > However, this can be discussed after adoption. Oleg has addressed

Re: [Emu] TEAP Request-Action TLV

> On 30 Apr 2020, at 20:53, Michael Richardson wrote: > > Signed PGP part > > Eliot Lear wrote: >> Here is a circumstance one could easily imagine, and in fact we >> attempted to address in draft-lear-eap-teap-brski: > >> Client requires a new ce

[Emu] TEAP Request-Action TLV

All: Here is a circumstance one could easily imagine, and in fact we attempted to address in draft-lear-eap-teap-brski: Client requires a new certificate for some reason or another. Perhaps its is about to expire, or perhaps the signer has been compromised, or what have you. We were thinking

Re: [Emu] draft-aura-eap-noob-08 NAI

Hi Mohit > On 24 Apr 2020, at 15:02, Mohit Sethi M > wrote: > > Hi Max, > > Tuomas can give you a definite answer. My understanding is that error > 1001 should be sent by the server if the received identity does not > follow the requirements of draft-aura-eap-noob. Besides, implementing >

Re: [Emu] My review ... was RE: I-D Action: draft-ietf-emu-eaptlscert-02.txt

> On 24 Mar 2020, at 10:30, Hannes Tschofenig wrote: > > Hi Eliot, > > I consider the enterprise and the university case as a roaming model. From an > EAP method point of view there is IMHO little difference between the roaming > and the non-roaming case: the EAP exchange always runs

Re: [Emu] My review ... was RE: I-D Action: draft-ietf-emu-eaptlscert-02.txt

> certificates/certificate chains occur would shine light on this aspect. > > Ciao > Hannes > > From: Eliot Lear > Sent: Tuesday, March 24, 2020 10:02 AM > To: Hannes Tschofenig > Cc: Michael Richardson ; emu@ietf.org > Subject: Re: [Emu] My review ... was

Re: [Emu] My review ... was RE: I-D Action: draft-ietf-emu-eaptlscert-02.txt

Good morning Hannes > > >> Also, >> from deployment experience, EAP peers typically have longer >> certificate chains than servers. > > I would like a reference to be included here. Theoretically, it makes no > sense to > have a certificate chain for an EAP peer to have a longer certificate

Re: [Emu] draft-lear-eap-teap-brski-05

Hi Hannes, N.B., this draft is undergoing a fair amount of change. However, what you are discussing wasn’t in scope for those particular changes, not that your points shouldn’t lead to changes if needed. > On 5 Mar 2020, at 18:20, Hannes Tschofenig wrote: > > Hi all, > > I have a

Re: [Emu] Processing of TEWAP erratum 5127

> On 27 Jan 2020, at 05:46, Joseph Salowey wrote: > > [Joe] THis is not the only the derivation could be interpreted. The null > after the label and the inclusion of the length are part of RFC 8295 and not > the TLS PRF. To fix this errata I think we should define the TLS-PRF to be > P_

  1   2   >