I am in favor of the switch back to draft-13 key derivations.
Jorge Vergara
From: Emu On Behalf Of Joseph Salowey
Sent: Sunday, May 9, 2021 10:54 AM
To: EMU WG
Subject: [Emu] Consensus call on EAP-TLS key derivation
We had discussion on the list on whether to include context in the key
whether
the draft-13 exporter is livable.
Jorge Vergara
From: Joseph Salowey
Sent: Friday, May 7, 2021 2:19 PM
To: Jorge Vergara
Cc: Alan DeKok ; EMU WG
Subject: Re: [Emu] WG Last Call for Using EAP-TLS with TLS 1.3
On Fri, May 7, 2021 at 1:09 PM Jorge Vergara
mailto:jover...@microsoft.com>
> When EAP-TLS is used with TLS version 1.3 the Key_Material, IV, and
> Method-Id SHALL be derived from the exporter_secret using the TLS
> exporter interface [RFC5705] (for TLS 1.3 this is defined in
> Section 7.5 of [RFC8446]).
>
> Type-Code = 0x0D
> MSK=
eceived for the peer/supplicant?
We're ironing out a few implementation issues.
>c. Did you run into any issues with this mechanism?
Yes, as above - but theoretically I don't see a technical issue once the kinks
are ironed out. We believe the signal should be acc
s. I'm happy to see discussion
occurring either way and hope my perspective as an implementor is useful in
driving toward a resolution.
Jorge Vergara
From: Emu On Behalf Of Joseph Salowey
Sent: Monday, February 1, 2021 11:32 AM
To: Alan DeKok
Cc: ; EMU WG ; Benjamin Kaduk
Subject: Re: [Em
is currently how the Windows client implementation operates, but it is
mostly by chance. If we made the full processing of the EAP-TLS packet
explicit, then I think this would resolve the concerns around ordering here.
Jorge Vergara
From: Emu On Behalf Of Joseph Salowey
Sent: Friday, January 29, 2021
w version within 24 h.
Totally open to this.
Jorge Vergara
-Original Message-
From: Alan DeKok
Sent: Friday, January 29, 2021 5:10 AM
To: John Mattsson
Cc: Jorge Vergara ; Martin Thomson
; Benjamin Kaduk ; Roman Danyliw
; ; EMU WG
Subject: Re: [TLS] [Emu] Fwd: Benjamin Kaduk's Discuss on
draft-
release cycle. Seeing as
we're sitting on draft-13 with multiple implementations available, I would
really prefer to reach consensus to finalize draft-13 and get this into the
hands of customers this calendar year.
Jorge Vergara
-Original Message-
From: Emu On Behalf Of Alan DeKok
Sent
This change looks good to me. Would appreciate a sanity check of another
implementation by Oleg to make sure I have my facts straight here.
From: Joseph Salowey
Sent: Sunday, November 22, 2020 9:24 PM
To: Jorge Vergara
Cc: Oleg Pekar ; EMU WG ; Jouni
Malinen
Subject: Re: Proposed Resolution
a final
pass-over.
Jorge Vergara
From: Oleg Pekar
Sent: Saturday, October 24, 2020 4:30 PM
To: Joseph Salowey
Cc: EMU WG ; Jouni Malinen ; Jorge Vergara
Subject: Re: Proposed Resolution for TEAP errata 5768
> 2 The EAP Type sent by the other party in the first TEAP message. This is a
>
ame and password authentication here.
Oleg made some comments to this effect on another email. Our implementation
doesn’t support basic username and password authentication so I don’t have any
prior experience here.
Jorge Vergara
From: Joseph Salowey
Sent: Saturday, October 24, 2020 5:18 PM
To: EMU WG
ern as the errata we are discussion. I am very
surprised to hear that Cisco’s implementation may be different. Oleg, could you
please double check? I have just double checked our implementation. Since our
implementations interop, I assume we must have the same implementation.
Jorge Vergara
it should avoid using the TLS 1.2 PRF since it is already
obsoleted in TLS 1.3.
Jorge Vergara
From: Oleg Pekar
Sent: Thursday, October 22, 2020 6:59 AM
To: Joseph Salowey
Cc: EMU WG ; Jorge Vergara ; Jouni
Malinen
Subject: Re: Proposed resolution for TEAP errata for 5128
Hi all,
Speaking
I agree with all the proposed resolutions. For context, there was some prior
discussion of this errata here:
https://mailarchive.ietf.org/arch/msg/emu/K_XWBMevKNdxdWskK8RkBt1ZpSQ/
Jorge Vergara
From: Joseph Salowey
Sent: Wednesday, October 21, 2020 5:13 PM
To: EMU WG ; Jouni Malinen ; Jorge
is portion of the RFC. Since this
calculation is not on an EMSK, I do not believe RFC 2395 applies and this is
likely why implementations went with the seedless P_(secret, label)
calculation instead.
Is there concern about updating the RFC in a way that breaks existing
implementations?
Jorge Ver
Does anyone else have any other thoughts on this? I'm not a TLS expert but
similarly value the TLS Fatal Alerts over using close_notify. If we will be
losing alerts then I would favor switching back to 0x00.
Jorge Vergara
-Original Message-
From: Alan DeKok
Sent: Wednesday, September
e better to define these calculation in
terms of the TLS-Exporter instead?
Jorge
From: Emu On Behalf Of Jorge Vergara
Sent: Wednesday, September 2, 2020 9:48 AM
To: Joseph Salowey ; Alan DeKok
Cc: emu@ietf.org
Subject: Re: [Emu] I-D Action: draft-ietf-emu-tls-eap-types-01.txt
>[Joe] Moving awa
: Joseph Salowey
Sent: Wednesday, September 2, 2020 8:53 AM
To: Alan DeKok
Cc: John Mattsson ; Jorge Vergara
; emu@ietf.org
Subject: Re: [Emu] I-D Action: draft-ietf-emu-tls-eap-types-01.txt
On Wed, Sep 2, 2020 at 7:54 AM Alan DeKok
mailto:al...@deployingradius.com>> wrote:
On Sep 2, 202
ght heavily in on
what the right thing to do is, but have no objection to moving away from SHA1.
Rather than locking in another dependency such as SHA256, I wonder if this
calculation should also use a hash function derived from the TLS handshake?
Jorge Vergara
-Original Message-
From:
ACK that EAP-TLS does not need to keep the connection open.
Question: should some consideration be given to consistency with other EAP
methods that do need to keep the connection open? i.e. PEAP/EAP-TTLS/TEAP
Jorge
-Original Message-
From: Emu On Behalf Of Jim Schaad
Sent: Saturday,
Windows expects an encrypted octet. My brain had automatically translated the
plaintext -> encrypted based on the timing of the commitment message - which
was apparently an incorrect translation at the time. Interop has been tested
with FreeRADIUS and hostapd.
-Original Message-
From:
ure gap – but servers are free to decline the connection if they do not
want to downgrade to an MSK based crypto binding.
From: Joseph Salowey
Sent: Monday, June 22, 2020 8:53 PM
To: Oleg Pekar
Cc: Jorge Vergara ; Jouni Malinen ; EMU WG
Subject: Re: [Emu] draft-dekok-emu-tls-eap-types discuss
-Original Message-
From: Alan DeKok
Sent: Tuesday, June 2, 2020 6:09 AM
To: Jorge Vergara
Cc: EMU WG
Subject: Re: [Emu] jovergar review of draft-dekok-emu-tls-eap-types-02
On Jun 2, 2020, at 3:29 AM, Jorge Vergara
wrote:
>>
>> I’ve attempted/completed a prototype im
te the effort gone into this thus far. I believe the adjustments
needed are fairly simple and after the above issues are solved I could complete
my prototypes.
Thanks,
Jorge Vergara
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
From: Joseph Salowey
Sent: Monday, May 25, 2020 9:27 PM
To: Jorge Vergara
Cc: Oleg Pekar ; Jouni Malinen ; EMU WG
Subject: Re: [Emu] TEAP - RFC 7170 - Errata ID 5768
On Fri, May 22, 2020 at 1:18 PM Jorge Vergara
mailto:40microsoft@dmarc.ietf.org>>
wrote:
My review of this
I am going to consider these 3 errata separately as I think it is clearest:
Errata ID 5767:
I believe Jouni’s differentiation of an “EAP authentication method” vs “EAP
method” is that an “EAP authentication method” has a type >= 4. Jouni mentions
this in his errata filing and it is also
My review of this errata and the current responses from Oleg:
1. I agree with this proposed resolution. I do think this is an important
omission that needs to be clarified in the RFC. Otherwise it is somewhat
guesswork that truncation is the right action. I think the current wording
leans
ot derive either MSK or EMSK, then I believe the RFC addresses this as MSKi =
32 octets of 0x00s. So if one side calculated neither MSK nor EMSK, and both
sides decided to continue the conversion, then both sides would use the
zero-MSK for that IMSK[j],
Jorge Vergara
-Original Message-
Fr
es.
Jorge Vergara
-Original Message-
From: Alan DeKok
Sent: Sunday, April 19, 2020 9:17 AM
To: Jorge Vergara
Cc: EMU WG
Subject: Re: [Emu] draft-dekok-emu-tls-eap-types discussion
On Apr 7, 2020, at 5:09 PM, Jorge Vergara wrote:
> On the document contents themselves, I have this re
the errata.
Jorge
From: Emu On Behalf Of Oleg Pekar
Sent: Wednesday, April 15, 2020 9:25 AM
To: Jorge Vergara
Cc: EMU WG
Subject: Re: [Emu] draft-dekok-emu-tls-eap-types discussion
Hi Jorge,
For Microsoft supported protocol suite PEAP/TTLS/TEAP - are you planning to
find the common method
>Microsoft has already said that they won't rev their EAP-TLS implementation
>until they can also rev PEAP.
PEAP/TTLS/TEAP - we (Microsoft) believe all should be addressed at the same
time and will postpone TLS 1.3 support until such a time as we are able to make
the updates together.
>*
> Since it looks like TEAP hasn't actually been implemented much, it's probably
> best to move the TLS 1.3 fixes into a general "oops, we need to fix TEAP"
> document.
I can understand the reasoning here, but it's my opinion that we should default
to including TEAP changes for TLS1.3 in
ses IMSK[j], which may be equivalent in some cases, but
may not in others where the inner method exports an EMSK. I understand there
may be a TEAP errata related to this and I may not be fully up to date on the
errata discussion, so perhaps this is already taken into consideration.
Jorge Vergara
---
33 matches
Mail list logo
