>>DISCUSS: We have interoperable implementations of -13. Does this mean that
>>the EAP state machines *implicitly* work with the TLS state machines? There
>>is no *explicit* requirement in the draft about ordering, and no discussion
>>thereof. I suspect that this means the implementations
In order to better validate existing implementations of EAP-TLS 1.3, we
will be organizing an EAP-TLS 1.3 Hackathon at IETF 110.
The goal of the hackathon is to test operating system client
implementations (Android, iOS, Mac OS X, Windows) with server
implementations over the Internet.
If you
HI Alan,
THanks for this message, comments inline below:
On Fri, Jan 29, 2021 at 12:02 PM Alan DeKok
wrote:
> This is a new message to summarize history, requirements, etc. for
> EAP-TLS and TLS 1.3. The focus here is the requirements for EAP-TLS, and
> how the 0x00 commitment message
On Fri, Jan 29, 2021 at 11:34 AM Mohit Sethi M wrote:
> Hi Ben,
> On 1/29/21 8:32 PM, Benjamin Kaduk wrote:
>
> Hi Alan,
>
> I see that the thread is continuing and that perhaps my reply will even
> become stale as I write it, but I'm replying to your note instead of the
> tip of the thread
This is a new message to summarize history, requirements, etc. for EAP-TLS
and TLS 1.3. The focus here is the requirements for EAP-TLS, and how the 0x00
commitment message versus CloseNotify meets those. I'll ignore the exporter
changes here, as those are less controversial.
The original
Hi Ben,
On 1/29/21 8:32 PM, Benjamin Kaduk wrote:
Hi Alan,
I see that the thread is continuing and that perhaps my reply will even
become stale as I write it, but I'm replying to your note instead of the
tip of the thread because it has good context for making some broader
points that I would
On Jan 29, 2021, at 1:32 PM, Benjamin Kaduk wrote:
> With respect to the exporter usage, I do see you had asked about using the
> type-code as the exporter context value that Martin didn't see much value
> in, but I am willing to accept that as a boon for safety of portability to
> other
Hi Alan,
I see that the thread is continuing and that perhaps my reply will even
become stale as I write it, but I'm replying to your note instead of the
tip of the thread because it has good context for making some broader
points that I would like to make.
On Sat, Jan 23, 2021 at 05:28:10PM
> We need to get agreement on how to proceed here asap. I would like
> implementors and security AD to agree on the way forward before submitting
> -14. Four ways forward:
>
> A. Add (1) and (2)
> B. Only add (1)
> C. Only add (2)
> D. Do not add (1) or (2)
My preference is D.
> Do we need to
On Jan 29, 2021, at 8:10 AM, Alan DeKok wrote:
> Then our choices are:
>
> a) draft-13 in February. There are multiple interoperable implementations,
> including Microsoft, FreeRADIUS, and hostap / wpa_supplicant.
>
> b) ??? in 2021.
Typo: 2022. :(
On Jan 29, 2021, at 5:31 AM, John Mattsson wrote:
>
> I can live with any version, the important thing is that interoperable
> implementations get shipped ASAP. This is important also for 3GPP as EAP-TLS
> 1.3 is mandatory to support in 3GPP Rel-16 if EAP-TLS is supported.
Then our choices
Hi,
I can live with any version, the important thing is that interoperable
implementations get shipped ASAP. This is important also for 3GPP as EAP-TLS
1.3 is mandatory to support in 3GPP Rel-16 if EAP-TLS is supported.
We (the authors) have addressed all the comments from IESG/TLS WG in
12 matches
Mail list logo
