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

2021-07-05 Thread Eliot Lear
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

2021-07-03 Thread Eliot Lear
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

2021-07-01 Thread Eliot Lear
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

2021-06-30 Thread Eliot Lear
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

2021-05-17 Thread Eliot Lear
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

2021-04-12 Thread Eliot Lear
> 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

2021-04-12 Thread Eliot Lear
> 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

2021-04-12 Thread Eliot Lear
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

2021-04-12 Thread Eliot Lear
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

2021-02-19 Thread Eliot Lear
> 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

2020-11-28 Thread Eliot Lear
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

2020-11-02 Thread Eliot Lear
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

2020-11-02 Thread Eliot Lear
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

2020-10-29 Thread Eliot Lear
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

2020-10-29 Thread Eliot Lear
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

2020-10-27 Thread Eliot Lear
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

2020-10-26 Thread Eliot Lear
[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

2020-10-26 Thread Eliot Lear
> 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

2020-10-26 Thread Eliot Lear
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

2020-10-26 Thread Eliot Lear
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

2020-10-23 Thread Eliot Lear
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

2020-10-22 Thread Eliot Lear
+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)

2020-05-20 Thread Eliot Lear
>> ------ >> 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)

2020-05-04 Thread Eliot Lear
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

2020-04-30 Thread Eliot Lear
> 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

2020-04-30 Thread Eliot Lear
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

2020-04-24 Thread Eliot Lear
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

2020-03-24 Thread Eliot Lear
> 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

2020-03-24 Thread Eliot Lear
> 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

2020-03-24 Thread Eliot Lear
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

2020-03-05 Thread Eliot Lear
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

2020-01-28 Thread Eliot Lear
> 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_

[Emu] RFC 7170 Erratum 5844

2020-01-22 Thread Eliot Lear
If we accept erratum 5845, then it seems only natural that we should accept this erratum as well. > Section 3.3.1 says: > >EAP method messages are carried within EAP-Payload TLVs defined in >Section 4.2.10. If more than one method is going to be executed in >the tunnel, then upon

[Emu] RFC 7170 Erratum 5845

2020-01-22 Thread Eliot Lear
Hi Jouni and all, Getting back to 7170 errata. You wrote: > Section 3.3.1 says: > >EAP method messages are carried within EAP-Payload TLVs defined in >Section 4.2.10. If more than one method is going to be executed in >the tunnel, then upon method completion, the server MUST send

Re: [Emu] [lamps] EAP/EMU recommendations for client cert validation logic

2020-01-16 Thread Eliot Lear (elear)
On 8 Jan 2020, at 17:29, Ryan Sleevi mailto:ryan-i...@sleevi.com>> wrote: The CA must revoke if the certificate is misused; that's required by contract. The CA defines what misuse means. A number of CAs define misuse as "used for purposes other than TLS web server" Ergo, obtaining and using

Re: [Emu] BRSKI-TEAP vs regular connection (was Re: EAP questions ...)

2020-01-15 Thread Eliot Lear (elear)
> On 15 Jan 2020, at 16:10, Michael Richardson wrote: > > > Eliot Lear (elear) wrote: >>> Owen, do we have a need to recognize that a device needs to perform >>> onboarding again after a movement? >>> >>> i.e. device A enrolls on network

Re: [Emu] BRSKI-TEAP vs regular connection (was Re: EAP questions ...)

2020-01-15 Thread Eliot Lear (elear)
Hi Michael, > > Owen, do we have a need to recognize that a device needs to perform > onboarding again after a movement? > > i.e. device A enrolls on network 1, gets an LDevID usable on network 1, > uses that with EAP-FOOBAR. > > device A then is moved to network 2, it tries to use same

Re: [Emu] [lamps] EAP/EMU recommendations for client cert validation logic

2020-01-08 Thread Eliot Lear (elear)
, 2020 at 5:00 AM Eliot Lear (elear) mailto:el...@cisco.com>> wrote: Hi Ryan, This topic seems like a good one to just get on the phone and sort through, but I have one question: On 8 Jan 2020, at 09:11, Ryan Sleevi mailto:ryan-i...@sleevi.com>> wrote: However, if using the same set o

Re: [Emu] [lamps] EAP/EMU recommendations for client cert validation logic

2020-01-08 Thread Eliot Lear (elear)
Hi Ryan, This topic seems like a good one to just get on the phone and sort through, but I have one question: On 8 Jan 2020, at 09:11, Ryan Sleevi mailto:ryan-i...@sleevi.com>> wrote: However, if using the same set or CAs that popular OSes use for TLS, it does mean that these CAs, and their

Re: [Emu] Processing of TEWAP erratum 5127

2019-11-25 Thread Eliot Lear
Hi Juoni, Thanks for taking the time. I suspect this will take a few iterations to get the actual text right, as I am drinking water from a fire hose here. Please bear with me. > On 24 Nov 2019, at 12:31, Jouni Malinen wrote: > > On Fri, Nov 22, 2019 at 05:21:10PM +0800, Eliot L

Re: [Emu] POST WGLC Comments draft-ietf-emu-eap-tls13

2019-11-01 Thread Eliot Lear
Hi! > On 1 Nov 2019, at 13:05, Alan DeKok wrote: > > On Nov 1, 2019, at 7:53 AM, Eliot Lear wrote: >> >>> The EAP Identity used in resumption SHOULD be the same EAP Identity as was >>> used during the original authentication. This requirement allows EAP &

Re: [Emu] POST WGLC Comments draft-ietf-emu-eap-tls13

2019-11-01 Thread Eliot Lear
Thanks, Alan. Please see below. > On 1 Nov 2019, at 12:08, Alan DeKok wrote: > > On Nov 1, 2019, at 6:15 AM, John Mattsson wrote: >> I strongly support working group adoption of draft-dekok-emu-tls-eap-types. >> Can we make sure to get this document going, I agree that this is a very >>

Re: [Emu] POST WGLC Comments draft-ietf-emu-eap-tls13

2019-10-30 Thread Eliot Lear
> On 30 Oct 2019, at 06:22, Joseph Salowey wrote: > > > > On Fri, Oct 11, 2019 at 7:34 AM Eliot Lear <mailto:l...@cisco.com>> wrote: > > > > On 11 Oct 2019, at 16:09, Michael Richardson > <mailto:m...@sandelman.ca>> wrote: > > > &g

Re: [Emu] POST WGLC Comments draft-ietf-emu-eap-tls13

2019-10-11 Thread Eliot Lear
> On 11 Oct 2019, at 16:09, Michael Richardson wrote: > > So, can wired just be a degenerate version of wifi, where there can be only > one "ESSID", and there are no beacons to consider? On the whole that has been my thought. But it is a matter of which mechanism to degenerate to. Is it

Re: [Emu] POST WGLC Comments draft-ietf-emu-eap-tls13

2019-10-11 Thread Eliot Lear
> On 11 Oct 2019, at 13:04, Michael Richardson wrote: > > > Eliot Lear wrote: >> Before we nail this down, it seems like we need to have a discussion >> about how best to onboard wired IoT devices in particular from an >> on-prem view. The issue here

Re: [Emu] POST WGLC Comments draft-ietf-emu-eap-tls13

2019-10-10 Thread Eliot Lear
-PSK does not provide PFS, and EAP-PWD is not >> suitable for IoT. I strongly think we need an EAP method with PSK + PFS for >> IoT, and the easiest way to achieve that seems to be EAP-TLS-PSK. >> >> Cheers, >> John >> >> From: Eliot Lear <mailto:l...@c

Re: [Emu] TEAP errata 5770

2019-10-10 Thread Eliot Lear
Just one comment: TEAP does not require an inner method, and indeed for IoT it is not necessary. Eliot > On 9 Oct 2019, at 07:46, Joseph Salowey wrote: > > Based on Jouni's analysis the derivation of the S-IMCKs is not well > specified. To me it looks like the solution to handle an

Re: [Emu] POST WGLC Comments draft-ietf-emu-eap-tls13

2019-10-10 Thread Eliot Lear
provide PFS, and EAP-PWD is not suitable for IoT. > I strongly think we need an EAP method with PSK + PFS for IoT, and the > easiest way to achieve that seems to be EAP-TLS-PSK. > > Cheers, > John > > From: Eliot Lear mailto:l...@cisco.com>> > Date: Thursday,

Re: [Emu] POST WGLC Comments draft-ietf-emu-eap-tls13

2019-10-07 Thread Eliot Lear
> On 7 Oct 2019, at 15:10, Alan DeKok wrote: > > On Oct 7, 2019, at 2:32 AM, John Mattsson > wrote: >> >> Joseph Salowey wrote: >> >>> Is the current published version up to date with the rest of the comments? >> >> Yes, to my knowledge, the current draft handles all the other comments.

[Emu] Another side meeting on IOT onboarding

2019-03-25 Thread Eliot Lear
For those who are interested, we will be continuing our IoT Onboarding discussion Wednesday @ 2:00pm in Karlin 3. Topics will include review of the various onboarding mechanisms that we listed on Github, review of the questions we were asking, some live editing of THAT, and some mapping of all

Re: [Emu] Review of draft-ietf-emu-eap-tls13-04

2019-03-21 Thread Eliot Lear
Hi > On 20 Mar 2019, at 11:03, Jim Schaad wrote: > > TLS 1.3 introduced early application data; if a server receives a client > hello with early application data it MUST abort the handshake with an > EAP-Failure. The server MAY generate a TLS-Alert as well. This precise text actually may

Re: [Emu] [Iot-onboarding] On boarding again

2019-03-06 Thread Eliot Lear
d. Please notify us immediately of the error by return > e-mail and please delete this message from your system. > > > > On Wed, Mar 6, 2019 at 2:32 PM Eliot Lear <mailto:l...@cisco.com>> wrote: > Hi everyone, > > For those who are interested in discussing on

Re: [Emu] Questions about EAP-NOOB

2019-03-06 Thread Eliot Lear
Hi Aura, Just on this one point: > On 6 Mar 2019, at 13:23, Aura Tuomas wrote: > > > The realm used by the peer is initially “eap-noob.net > ”. The server can assign another realm in Initial > Exchange. The main purpose for assigning another realm is that the peer can

Re: [Emu] Questions about EAP-NOOB

2019-03-06 Thread Eliot Lear
And indeed it was Alan who I was referring to in my message. I generally agree with Alan’s thinking below. Eliot > On 6 Mar 2019, at 13:45, Alan DeKok wrote: > > On Mar 6, 2019, at 7:23 AM, Aura Tuomas wrote: >> The realm used by the peer is initially “eap-noob.net”. The server can >>

[Emu] On boarding again

2019-03-06 Thread Eliot Lear
Hi everyone, For those who are interested in discussing onboarding, I’ve reserved an hour on Wednesday afternoon (27 Mar) at 14:00 at the IETF in Karlin 3. Since our last conversation, a few of us put a bit of an inventory together, regarding the mechanisms that are available. Some of the

[Emu] side meeting on IoT onboarding

2018-11-07 Thread Eliot Lear
Hi everyone, Thanks to those 30 or so people who participated in a side meeting just after OPSAWG on IoT onboarding.  There was pretty clear agreement that there is at least some fragmentation occurring in onboarding solutions, leading to some confusion amongst some of the players.  In some

[Emu] change of venue: onboarding side meeting

2018-11-05 Thread Eliot Lear
As we seem to have a lot of interest in the topic of onboarding, we are at risk of overflowing the very small room we were assigned.  Therefore, the side meeting will now take place immediately after OPSAWG in Chitlada 2. This meeting is intended as a discussion about whatever common

Re: [Emu] [Anima] ship and forget use cases for onboarding

2018-10-23 Thread Eliot Lear
Hi Michael, On 22.10.18 21:54, Michael Richardson wrote: > > > https://en.wikipedia.org/wiki/Joe_Isuzu ... I asked google, and I'm not > quite sure I get the connection. Sorry- this was a reference to an earlier message.  There is a mode in which the MASA is acting based on its relationship

Re: [Emu] Fwd: New Version Notification for draft-lear-brski-pop-00.txt

2018-10-22 Thread Eliot Lear
[Christian, read down a ways] On 22.10.18 20:15, Michael Richardson wrote: > Eliot, thanks for this document. If nothing else, it means that > we BRSKI authors can deal with some review comments by pointing to "future > work" :-) > > (A)"request-voucher-with-possession" <-- what about intent to

[Emu] Fwd: New Version Notification for draft-lear-brski-pop-00.txt

2018-10-20 Thread Eliot Lear
-00.txt has been successfully submitted by Eliot Lear and posted to the IETF repository. Name: draft-lear-brski-pop Revision: 00 Title: Proof of Possession to Devices for Onboarding Document date: 2018-10-20 Group: Individual Submission Pages: 7 URL

Re: [Emu] Comments on draft-lear-eap-teap-brski

2018-10-09 Thread Eliot Lear
Hi Alan, My apologies for the long delay in this reply On 21.07.18 16:11, Alan DeKok wrote: > One of the confusions from the meeting was "How can a device authenticate > via 802.1X if it doesn't trust the network?" > > I think the confusion is due to terminology. The discussion in the >