Re: [Emu] draft-ietf-emu-tls-eap-types-06 comments

2022-06-20 Thread Alan DeKok
S-CHAP could be EAP-MSCHAP-V2 or > possibly EAP-MD5? A replacement for MS-CHAPv1 is MS-CHAPv2, or EAP-MSCHAPv2 > > 8. References > +++ > [PEAP-MPPE], [PEAP-PRF] and [PEAP-TK] point to different parts of [MSPEAP]. > It might be useful to clarify that this is the case in order to minimise the > problem with broken links. I'll add some clarifying text. Thanks for the comprehensive review. Alan DeKok. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] Working Group Last Call for draft-ietf-emu-tls-eap-types

2022-06-14 Thread Alan DeKok
On Jun 14, 2022, at 2:09 PM, Russ Housley wrote: > > I think you should just say that: TTLS, PEAP, and FAST each have > method-specific application data. Done. > This resolves all of my concerns. Thanks. I'll push another version of the document at the end of the last c

Re: [Emu] Working Group Last Call for draft-ietf-emu-tls-eap-types

2022-06-14 Thread Alan DeKok
it would be more clear to say that the inclusion of the logical Type > makes the result method-specific. OK. I'll update the text. > > Nit: The author on the title page should be "A. DeKok" Fixed, thanks. Alan DeKok. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] Working Group Last Call for draft-ietf-emu-tls-eap-types

2022-06-09 Thread Alan DeKok
As author, I support it. Implementations are hostap, Windows, FreeRADIUS, and Radiator. > On Jun 8, 2022, at 12:16 PM, Joseph Salowey wrote: > > This is the working group last call for draft-ietf-emu-tls-eap-types. You > can find the document here: > >

Re: [Emu] Final 2 notes on draft-ietf-emu-tls-eap-types-03.txt

2022-05-25 Thread Alan DeKok
On Mar 23, 2022, at 1:02 PM, Alan DeKok wrote: > 2) the draft should be updated to add a note that when a supplicant sends > PAP/CHAP for phase 2 of TTLS, the expected responses are: > > EAP-Success > EAP-Failure > Ongoing TLS negotiation, with a

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

2022-04-01 Thread Alan DeKok
+1 Other than that, they look OK, thanks. > On Apr 1, 2022, at 1:16 AM, Bernard Aboba wrote: > > I think the note in eid6259 is now superfluous. Can we remove it? > > On Thu, Mar 31, 2022 at 10:09 PM Independent Submissions Editor (Eliot Lear) > wrote: > Corrected URLs below: > > On

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

2022-03-31 Thread Alan DeKok
received EAP-Response/Nak. This allows a peer to suggest another > EAP method where the NAS is configured to send a default EAP > type (such as MD5-Challenge) which may not be appropriate." That looks good to me, thanks. Alan DeKok. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu

[Emu] TEAP parameters registry?

2022-03-31 Thread Alan DeKok
as is done for FAST? Alan DeKok. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu

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

2022-03-31 Thread Alan DeKok
the peer MAY respond with a Nak indicating that it would prefer another authentication method that is implemented by the RADIUS server, and not by the NAS. In this case, the NAS SHOULD send an Access-Request encapsulating the received EAP-Response/Nak. I hope that addresses all concerns

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

2022-03-31 Thread Alan DeKok
lues for attributes in general but prohibits for > any declared types of the attributes. Yes. RADIUS is weird and terrible. Alan DeKok. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] Provisioning, configuration, etc. and EAP

2022-03-29 Thread Alan DeKok
gardens / captive portals. It shouldn't be difficult to extend that functionality with basic provisioning methods based on DNS / web. Which the systems already have. Alan DeKok. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] Provisioning, configuration, etc. and EAP

2022-03-28 Thread Alan DeKok
aving renewals spread across time, but there are > also disadvantages as it spreads the failure signal across time as well which > makes it harder to see that there is a real problem. Generally if people can't renew, the server should log errors, or the end user device has a real network wh

Re: [Emu] Provisioning, configuration, etc. and EAP

2022-03-28 Thread Alan DeKok
CPv4. Yes. I'm not sure that VLANs are a limited resource, or are difficult to provision. GVRP has existed for a while... Alan DeKok. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] Provisioning, configuration, etc. and EAP

2022-03-27 Thread Alan DeKok
is that the products are a collection of things from different standards bodies, who often don't communicate well with each other. Alan DeKok. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] Provisioning, configuration, etc. and EAP

2022-03-27 Thread Alan DeKok
ing/ > > but that section hasn't happened yet. I saw that. :( Alan DeKok. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] Provisioning, configuration, etc. and EAP

2022-03-25 Thread Alan DeKok
y using existing networking protocols. For example, RFC 8572 provides for similar tools (DNS SRV records + YAML / RESTCONF) for provisioning devices. If it works for devices, why not do something similar for end-user devices? Alan DeKok. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu

[Emu] Provisioning, configuration, etc. and EAP

2022-03-25 Thread Alan DeKok
od reasons for using EAP here. But I can't help but wonder if there's a better way that 3-4 different methods which all layer on top of EAP. Alan DeKok. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu

[Emu] Final 2 notes on draft-ietf-emu-tls-eap-types-03.txt

2022-03-23 Thread Alan DeKok
ver has no intention of doing resumption. If there are no objections or comments, I'll update the draft with some text saying the above. I'll issue a new version next week. Alan DeKok. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] EAP-CREDS - Question about Implementations

2022-03-22 Thread Alan DeKok
That makes EAP unsuitable for anything other than the most trivial of bootstrapping / management methods. Alan DeKok. ___ 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

2022-03-11 Thread Alan DeKok
the packets to the hosting provider, who would then use the inner identity to authenticate the user. IMHO this practice should be strongly discouraged, for reasons discussed in the draft. Alan DeKok. ___ 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

2022-03-07 Thread Alan DeKok
it didn't work historically. I think it's a good idea to forbid (a) duplicate features, and (b) features no one uses, and (c) features we're not sure have any value. Alan DeKok. ___ 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

2022-03-04 Thread Alan DeKok
they always have to expect and > require at minimum 0x00 octet over a TLSv1.3 tunnel when an EAP-based TLS > method is about to skip tunnelled authentication. Agreed. I'll add some text. Alan DeKok. ___ 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

2022-02-22 Thread Alan DeKok
On Feb 21, 2022, at 9:30 AM, Jan-Frederik Rieckers wrote: > I have found some small typos. Thanks. I've fixed them all. I'll issue a new version at the end of the WGLC. Alan DeKok. ___ Emu mailing list Emu@ietf.org https://www.ietf.

Re: [Emu] Working Group Last Call for TLS-based EAP types and TLS 1.3

2022-02-21 Thread Alan DeKok
t;. The authentication request could then be routed to the "example.org" domain, which would have no idea what to do with the credentials for "u...@example.com". At best, the authentication request would be discarded. At worst, the "example.org" domain could harvest use

Re: [Emu] Working Group Last Call for TLS-based EAP types and TLS 1.3

2022-02-20 Thread Alan DeKok
On Feb 19, 2022, at 12:07 PM, Russ Housley wrote: > > For TLS 1.3, the message authentication code (MAC) is compute with the HMAC > algorithm ... Sure, thanks. Alan DeKok. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman

Re: [Emu] Working Group Last Call for TLS-based EAP types and TLS 1.3

2022-02-19 Thread Alan DeKok
on / incompatibility issues. RFC 9190 has a significant discussion of TLS alerts already, and this document just references that. > - "concatetation" > "cloude" > "changover" > "deriviation" > "authenticaton" > "succeeed" > "identies" (several places) > "ciphersuite" (TLS uses the spelling cipher suite) > "NewSessionTicketMessage" (NEW: NewSessionTicket message) Fixed, thanks. Alan DeKok. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu

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

2022-02-17 Thread Alan DeKok
in the document as a result of reviews. But as a matter of process, it seems very broken to me we require a WGLC in order for people to review a WG document. This seems like a very problematic change in the IETF process. Alan DeKok. ___ Emu

[Emu] draft-ietf-emu-tls-eap-types

2022-02-16 Thread Alan DeKok
. And there was minimal discussion on it since then. Can we issue a WGLC, and get it published? Alan DeKok. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] Version Notification for draft-dekok-emu-eap-usability-00.txt

2022-02-15 Thread Alan DeKok
open questions. Alan DeKok. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] Version Notification for draft-dekok-emu-eap-usability-00.txt

2022-02-11 Thread Alan DeKok
ears ago. It never got traction, so he went to the WiFi alliance. Their latest spec now mandates an XML configuration format. Alan DeKok. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] EMU Meetings

2022-01-25 Thread Alan DeKok
eting on? There's not a lot left which is critical, I think. Alan DeKok. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] I-D Action: draft-ietf-emu-tls-eap-types-04.txt

2022-01-21 Thread Alan DeKok
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 : TLS-based EAP types and TLS 1.3 > Author : Alan DeKok >

Re: [Emu] EMU Meetings

2022-01-19 Thread Alan DeKok
so has issues > with publicizing identities. > > John: I think the only thing that is missing is to mandate use of ananymous > NAIs. I don't see any provision in the draft for providing a "real" identity. So the only NAI used is the outer one, which therefore cannot be fully anonymized. Alan DeKok. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] EMU Meetings

2022-01-18 Thread Alan DeKok
must be public, which compromises privacy. I'm not sure how this is preferable to TTLS + PAP. >draft-ingles-eap-edhoc That seems useful for limited situations (i.e. IoT). It also has issues with publicizing identities. >draft-chen-emu-eap-tls-ibs I have th

Re: [Emu] I-D Action: draft-ietf-emu-tls-eap-types-03.txt

2022-01-17 Thread Alan DeKok
On Jan 15, 2022, at 5:53 AM, John Mattsson wrote: > > On Oct 18, 2021, Alan DeKok wrote: > > >Implementors are doing final interoperability testing on client && server > >implementations. We hope to have updates within a few weeks, > > Any updates on thi

Re: [Emu] I-D Action: draft-ietf-emu-tls-eap-types-03.txt

2021-10-18 Thread Alan DeKok
e to have updates within a few weeks, > I agree with Alan that it would be good if it is published quite soon after > EAP-TLS 1.3. It is important to begin transitioning all the TLS based EAP > methods to TLS 1.3. I agree. Alan DeKok. __

Re: [Emu] Question of piggybacking in EAP

2021-09-27 Thread Alan DeKok
IUS Access-Request. > > So my question is, besides EAP-TTLS, is there an EAP protocol that is widely > supported and can be used for piggybacking a customized protocol? > Thanks,. TTLS seems like the best approach. Inside of that you can use EAP-Message, and a vendor-sp

Re: [Emu] Identities and draft-ietf-emu-tls-eap-types-03

2021-08-03 Thread Alan DeKok
e discuss it before this conversation. If it's widely used, then the draft should allow it. If it's rare to non-existent, then IMHO the draft should suggest it's not a good idea. Alan DeKok. ___ Emu mailing list Emu@ietf.org https://www.ietf.or

Re: [Emu] Identities and draft-ietf-emu-tls-eap-types-03

2021-08-03 Thread Alan DeKok
plain when that's used, and why. Alan DeKok. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] Identities and draft-ietf-emu-tls-eap-types-03

2021-08-03 Thread Alan DeKok
he inner identity is controlled and provisioned by the provider. So I can't think of many good reasons to have different outer/inner realms. The use-cases are small, and rare. I'm OK with not forbidding it. But I think there needs to be strong language saying "this is a terribl

Re: [Emu] Identities and draft-ietf-emu-tls-eap-types-03

2021-07-30 Thread Alan DeKok
en the inner realm cannot be "usern...@example.org". > On Jul 26, 2021, at 7:45 AM, Alan DeKok wrote: > > I propose to add a new section which discusses identities. > > As background, an (un-named) vendor recently made changes to their EAP > stack. The config

Re: [Emu] Short review of draft-friel-tls-eap-dpp-01

2021-07-28 Thread Alan DeKok
> TLS to authenticate it using tools which were defined to authenticate TLS. > We're just > proposing to use those tools in a new way. Yup. Alan DeKok. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] Short review of draft-friel-tls-eap-dpp-01

2021-07-28 Thread Alan DeKok
of generality) use another method, such as client certificates. > I don't think you're trying to solve the same problem we are. Pretty much. I suspect there may be some overlap, and I'd like to see if there's some possible synergy. > Nowhere do we propose to us

Re: [Emu] Short review of draft-friel-tls-eap-dpp-01

2021-07-28 Thread Alan DeKok
On Jul 27, 2021, at 1:50 PM, Alan DeKok wrote: >> We are trying to avoid wheel reinvention. The novel bit here is the mutual >> authentication in the TLS stack based on the already defined Wi-Fi Alliance >> DPP bootstrap key. The novel bit in the EAP-DPP draft, yes.

Re: [Emu] Short review of draft-friel-tls-eap-dpp-01

2021-07-27 Thread Alan DeKok
es web PKI to bootstrap TLS-based EAP methods * it does provisioning over standard internet protocols, instead of extending the supplicant. I think both of the above are useful. Using EAP as a generic transport layer for provisioning seems like a poor choice. Alan DeKok. __

[Emu] Identities and draft-ietf-emu-tls-eap-types-03

2021-07-26 Thread Alan DeKok
I propose to add a new section which discusses identities. As background, an (un-named) vendor recently made changes to their EAP stack. The configuration for TTLS/PEAP now takes the external (anonymous) identity, and uses that as the inner identity. i.e. instead of sending

[Emu] Short review of draft-friel-tls-eap-dpp-01

2021-07-18 Thread Alan DeKok
t can be easier to write a simpler utility which downloads information. Among other benefits, there is also a clear separation of roles between network access, and configuration changes. Alan DeKok. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] Version Notification for draft-dekok-emu-eap-usability-00.txt

2021-07-16 Thread Alan DeKok
tive text earlier, then people would ask "why these decisions?", only to have them answered later in the document. Alan DeKok. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] Version Notification for draft-dekok-emu-eap-usability-00.txt

2021-07-15 Thread Alan DeKok
work connection available, everything else can be automatic. Alan DeKok. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu

[Emu] Version Notification for draft-dekok-emu-eap-usability-00.txt

2021-07-12 Thread Alan DeKok
/ comments are welcome. > Begin forwarded message: > > From: internet-dra...@ietf.org > Subject: New Version Notification for draft-dekok-emu-eap-usability-00.txt > Date: July 12, 2021 at 1:55:58 PM EDT > To: "Alan DeKok" > > > A new version of I-D, draft-dekok-e

Re: [Emu] WG Last Call for Using EAP-TLS with TLS 1.3 (draft-ietf-emu-eap-tls13-17)

2021-07-08 Thread Alan DeKok
On Jul 8, 2021, at 12:42 PM, Joseph Salowey wrote: > > I created PR that I think captures these suggestions and another editorial > fix - https://github.com/emu-wg/draft-ietf-emu-eap-tls13/pull/87 I think it looks good. Alan DeKok. __

Re: [Emu] WG Last Call for Using EAP-TLS with TLS 1.3 (draft-ietf-emu-eap-tls13-17)

2021-07-08 Thread Alan DeKok
to allow > seamless transition. Yes, that makes sense. Perhaps instead: SHOULD allow for the configuration of one or more trusted root (CA certificates) Alan DeKok. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu

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

2021-07-05 Thread Alan DeKok
ere, even at the EAP level. But They don't > all fit together well. I have a document I'll publish shortly. Alan DeKok. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu

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

2021-07-03 Thread Alan DeKok
ion in terms of the sorts of operations we would like to > see as part of the authentication process – as opposed to elsewhere. > > I see tremendous opportunity here, to be honest. But it's a lot of work. I agree. Alan DeKok. ___ Emu m

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

2021-07-03 Thread Alan DeKok
having them pay me to paper over issues in multiple products. Alan DeKok. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu

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

2021-07-02 Thread Alan DeKok
On Jul 1, 2021, at 10:08 AM, Eliot Lear wrote: > > 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. >

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

2021-07-01 Thread Alan DeKok
s unsolved. 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. Alan DeKok. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu

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

2021-06-30 Thread Alan DeKok
ion-Protocol-for-IEEE-.-Latze/6d755cf4d1ac1da25c8d02a2e5cba56212149d69 So we've had this capability for a decade. But no one has found time / interest in moving forward with it. This makes me think that TPM is not really the best choice here. Alan DeKok. ___

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

2021-06-28 Thread Alan DeKok
tto IoT devices, and routers that have IDevID. > RFC8995(BRSKI) can help, and Eliot has a proposal about how to run that over > TEAP. > There are other ways too, and most wind up with an LDevID deployed. That's good, but I suspect it will take a while to

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

2021-06-28 Thread Alan DeKok
s randomly change APIs, UIs, and workflows. It's all a horrible bodge which is productive for no one. Alan DeKok. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu

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

2021-06-28 Thread Alan DeKok
ne via physical examination in a secure network, or via some unique hardware identifier. I might be missing something from the whole TPM infrastructure, tho. Alan DeKok. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu

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

2021-06-28 Thread Alan DeKok
net > SSIDs? Not that I know of. > About usage of physical MAC address - maybe some client systems will not have > access to the physical MAC rather than just to a randomized MAC. That is true. My goal here is not to make things perfect, but to be able to manage a device, when tha

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

2021-06-28 Thread Alan DeKok
, and not the public / randomized MAC? I've seen this problem more and more in customer deployments. It's becoming a serious security issue. Alan DeKok. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] Minor PR on eap-tls13

2021-06-28 Thread Alan DeKok
On Jun 24, 2021, at 8:11 PM, Joseph Salowey wrote: > Actually, PR#83 removes the MAY that makes the authorization behavior on > resumption optional. Do you still think we need to add this text to section > 5.7? No, we can leave it as-is. A

Re: [Emu] I-D Action: draft-ietf-emu-tls-eap-types-03.txt

2021-06-22 Thread Alan DeKok
ed EAP types and TLS 1.3 > Author : Alan DeKok > Filename: draft-ietf-emu-tls-eap-types-03.txt > Pages : 15 > Date: 2021-06-22 > > Abstract: > EAP-TLS [RFC5216] is being updated for TLS 1.3 in [EAPTLS]. Many > oth

[Emu] Minor PR on eap-tls13

2021-06-22 Thread Alan DeKok
https://github.com/emu-wg/draft-ietf-emu-eap-tls13/issues/86 I didn't see anything on cross-protocol use of certs. i.e. Section 2.2 suggests that the certs contain an FQDN. But it's likely bad practice to allow the same cert to be used for EAP, and for WWW. There's some suggested text

Re: [Emu] Review of draft-ietf-emu-tls-eap-types-02

2021-06-21 Thread Alan DeKok
Function * EXPORTER: Extended >Session Key Generating Function * teapbind...@ietf.org” Fixed, thanks. > - The draft mentions “commitment message” several times, but you are probably > aware of that. Yes. Now that eap-tls13 no longer uses that, I'll update this draft to be in agreement with it. Alan DeKok. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] draft-ietf-emu-eap-tls13-16.txt

2021-06-18 Thread Alan DeKok
gest just deleting "While certificates > may have long validity periods,". There is already text describing that > certificates can have very short lifetimes. Sure, that works. The rest of the changes look good, thanks. Alan DeKok. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] draft-ietf-emu-eap-tls13-16.txt

2021-06-18 Thread Alan DeKok
es/84) to track this. > Thanks. Alan DeKok. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] draft-ietf-emu-eap-tls13-16.txt

2021-06-17 Thread Alan DeKok
here any other remaining issues that are not listed on GitHub? My review of a few days ago had extensive comments. It may be worth going through that and addressing each issue. Some of the items have been addressed, which is positive. However, it looks like all of my comments for Section 5 re

Re: [Emu] draft-ietf-emu-eap-tls13-16.txt

2021-06-13 Thread Alan DeKok
minimal new interoperability or > implementation requirements on EAP peers. > > [Joe] This does not seem to add to the specification. I agree that text doesn't add any new requirements to the specification. However, it's useful to make a note for implementors that while Section 2.2. is officially a new requirement in theory, there is little to do in practice, because implementations already meet these requirements. There has been similar text in many other specifications. Alan DeKok. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] draft-ietf-emu-eap-tls13-16.txt

2021-06-11 Thread Alan DeKok
ting text about negotiation, which might be inconsistent with the parent reference. The text isn't wrong, but it may be worth just saying something to the effect of "EAP-TLS does not do cryptographic negotiation, but instead relies on TLS. See Section

Re: [Emu] I-D Action: draft-ietf-emu-eap-tls13-16.txt

2021-06-11 Thread Alan DeKok
to get that particular response. It is distinctly unusual. Alan DeKok. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] I-D Action: draft-ietf-emu-eap-tls13-16.txt

2021-06-11 Thread Alan DeKok
ons, then it would be useful to address comments from major implementors. Alan DeKok. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] I-D Action: draft-ietf-emu-eap-tls13-16.txt

2021-06-11 Thread Alan DeKok
On Jun 11, 2021, at 9:08 AM, Mohit Sethi M wrote: > > Hi Chair/AD/EMU: > > We have submitted a new version of draft-ietf-emu-eap-tls13 based on the > extensive feedback from Alan Dekok, Heikki Vatiainen, and Oleg Pekar. > > Can we somehow prioritize this documen

[Emu] draft-ietf-emu-eap-tls13-16.txt

2021-06-11 Thread Alan DeKok
Some comments have been addressed, others not. The majority of the issues raised in my review have been silently ignored. Some issues are nits, some affect interoperability and security. Until these issues are addressed, the document is insufficient to guide a reader into creating a

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

2021-05-25 Thread Alan DeKok
not allow for >the server certificate to change without out-of-band validation of >the certificate and is therefore not suitable for many deployments >including ones where multiple EAP servers are deployed for high >availability. > > > On Thu, May 20, 2021 at 10:23

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

2021-05-19 Thread Alan DeKok
y a suffix which is one of the trusted server names. I think it's past the time where this document can ask supplicants to change their behavior. We know what the supplicants do, it's not wrong, and it seems to work. So let's document that, and move on. Alan DeKok.

Re: [Emu] WG Last Call for Using EAP-TLS with TLS 1.3

2021-05-17 Thread Alan DeKok
nts >MUST take care that the resulting access granted by AAA servers and > network authenticators is appropriate for >unauthenticated peers." Yes. Alan DeKok. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu

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

2021-05-17 Thread Alan DeKok
... and one or more server names ... Alan DeKok. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] Consensus call on EAP-TLS key derivation

2021-05-10 Thread Alan DeKok
or not to revert > some of the text in the key derivation section. If you object to the change > please state why. Please respond by May 20,2021. We should revert to the -13 key derivations. Alan DeKok. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu

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

2021-05-10 Thread Alan DeKok
ps we should > remove the TOFU mechanism text or state that it does not work well in all HA > configurations (where different servers use different certificates) Perhaps just state that it does not work well in HA configurations. I don't think TOFU can be secure here. Alan DeKok.

Re: [Emu] WG Last Call for Using EAP-TLS with TLS 1.3

2021-05-07 Thread Alan DeKok
in the EAP-TLS application, by passing EAP-TLS parameters to TLS key exporters. So the TLS layer has no concept of what MSK or EMSK are. As a result, the TLS layer should have minimal input into what those keys are, or how they are derived. Alan DeKok.

Re: [Emu] WG Last Call for Using EAP-TLS with TLS 1.3

2021-05-07 Thread Alan DeKok
" means I should be able to say the following, and be taken seriously: "Hi, as someone with running code, I believe that it is critical for the specification to say X, in order to address implementation and interoperability issues".

Re: [Emu] WG Last Call for Using EAP-TLS with TLS 1.3

2021-05-06 Thread Alan DeKok
> On May 5, 2021, at 11:33 AM, Joseph Salowey wrote: > > This is the working group last-call for draft-ietf-emu-eap-tls13. Please > review the draft, focus on the recent changes and submit your comments to the > list by May 20, 2021. Section 1 says: While this document updates

Re: [Emu] Issue 47 Certificate identity checks

2021-04-14 Thread Alan DeKok
3, I think the time is appropriate for making the server > certificate requirements more strict. This is likely the last chance for a > long time. I strongly suspect that there's no consensus here, and this really isn't the document to do it in. The issues are much lar

Re: [Emu] Issue 47 Certificate identity checks

2021-04-14 Thread Alan DeKok
least requiring an EAP-specific EKU or OID would require operating systems > to separate out the EAP trust store. I agree 100% there. > TLS Web Server Certificate should not be acceptable for EAP. Well, yes. The question is how do we get th

Re: [Emu] Issue 47 Certificate identity checks

2021-04-14 Thread Alan DeKok
d show the entire cert to the user. Now, many don't even do that. Some just show a fingerprint in a pop-up dialog, and ask the user "is this OK?". How that's useful to anyone is beyond me. Alan DeKok. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] Issue 59 - Key Update

2021-04-13 Thread Alan DeKok
d a key > update message so an implementation detecting the reception of a keyUpdate > message MAY process or ignore the message since only a minimum amount of > application data is exchanged in the channel." That's great, thanks. Alan DeKok. _

Re: [Emu] Issue 47 Certificate identity checks

2021-04-12 Thread Alan DeKok
S document, I suspect it's best to just say "here be dragons", and leave it at that. Any attempt to define new behavior may be time consuming. Alan DeKok. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] Issue 47 Certificate identity checks

2021-04-12 Thread Alan DeKok
organizations control (public CAs) Only if the peer doesn't notice if the server cert changes. I think it's safe to recommend that clients pin both the server cert and the CA cert. Anything else is "there be dragons". Alan DeKok. ___ Emu ma

Re: [Emu] Issue 47 Certificate identity checks

2021-04-12 Thread Alan DeKok
t could tell the difference between the "fake" server cert, and a real one. As a result, it looks like id-kp-eapOverLAN is not appropriate for server certs. Alan DeKok. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] Issue 47 Certificate identity checks

2021-04-12 Thread Alan DeKok
us one, and may be overly > broad. Let me give you an example: a device may be designed only to operate > as part of a federation. I would agure there that the federation should have it's own CA. I'm not sure what it means to have a federation where someone else cont

Re: [Emu] Issue 47 Certificate identity checks

2021-04-12 Thread Alan DeKok
n is the CA. If the CA is trusted, nothing else matters. If the CA is not trusted, then nothing else matters. i.e. for any kind of increased security you'd like to add to EAP-TLS, you can almost always find a scenario where that security forbids real-world use-cases we'd like to support.

Re: [Emu] Issue 59 - Key Update

2021-04-12 Thread Alan DeKok
don't know why you'd use it. But if someone else does use it, and it works, great. Otherwise, buyer beware". Alan DeKok. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] Issue 61 Clarifying NAI handling during resumption

2021-04-12 Thread Alan DeKok
realm works, because it's already been working with EAP for a decade. Alan DeKok. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu

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

2021-03-30 Thread Alan DeKok
to work around issues where the EAP peer and server ended up in an infinite loop ACKing their messages. ... Alan DeKok. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] Resolving EAP-TLS issues

2021-03-28 Thread Alan DeKok
no response (other than Bernard's short note) to the detailed review I posted to the list. On looking at the draft, none of the issues seem to be addressed. Alan DeKok. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu

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

2021-03-09 Thread Alan DeKok
;@realm" as a short-hand for the realm. But also that single-label realm names are forbidden by RFC 7542 Section 2.2. Alan DeKok. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] Github repo for EAP-TLS 1.3 document

2021-03-04 Thread Alan DeKok
R to update the document. Alan DeKok. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu

  1   2   3   4   5   >