Based on helpful WGLC feedback on draft-ietf-emu-rfc7170bis, we are now at
version -14. I'm not aware of any outstanding issues (minor errata stuff
aside) and there do not appear to be any objections, sustained or otherwise
at the present time. On that basis, your EMU WG chairs are declaring WG
con
On Sun, 27 Aug 2023, at 10:57, Heikki Vatiainen wrote:
> Weren't the observed differences against RFC 7170 one the main
> reasons why the draft was needed?
Exactly. In particular it was the use of the EAP-FAST-MSCHAPv2 key derivative
(reversed upper/lower bits) that triggered this and the fun aro
On Sat, 26 Aug 2023 at 21:13, Michael Richardson
wrote:
>
> Heikki Vatiainen wrote:
> > Test with Windows 11 and eapol_test - EAP-TLS followed by EAP-MSCHAPv2
>
> Are you saying that Windows 11 also has implemented (accessible via
> "insider
> program" only)?
>
I think TEAP has been generally a
On Aug 26, 2023, at 3:18 PM, Michael Richardson wrote:
> since some things have been clarified, are we sure then that it's on the side
> of the new text?
> (I'm asking as shepherd to record Implementation Status)
I won't speak for Microsoft as such. But all of the implementations do the
same
Alan DeKok wrote:
> On Aug 26, 2023, at 2:13 PM, Michael Richardson
> wrote:
>> Are you saying that Windows 11 also has implemented (accessible via
>> "insider program" only)?
> I believe that TEAP is generally available in Windows 11.
since some things have been clarifie
On Aug 26, 2023, at 2:13 PM, Michael Richardson wrote:
> Are you saying that Windows 11 also has implemented (accessible via "insider
> program" only)?
I believe that TEAP is generally available in Windows 11.
https://learn.microsoft.com/en-us/windows-server/networking/technologies/extensib
Heikki Vatiainen wrote:
> Test with Windows 11 and eapol_test - EAP-TLS followed by EAP-MSCHAPv2
Are you saying that Windows 11 also has implemented (accessible via "insider
program" only)?
Bernard could you confirm?
--
Michael Richardson. o O ( IPv6 IøT consulting )
Sandelman
On Aug 25, 2023, at 2:10 PM, Heikki Vatiainen wrote:
> When the outer TLS-based EAP is processed by a different EAP server than the
> inner EAP-TLS, then the why inner EAP-TLS resumption shouldn't be simply a
> matter of the EAP peer and the inner EAP server? In this case the outer EAP
> server
On Fri, 25 Aug 2023, at 19:10, Heikki Vatiainen wrote:
> When the outer TLS-based EAP is processed by a different EAP server than the
> inner EAP-TLS, then the why inner EAP-TLS resumption shouldn't be simply a
> matter of the EAP peer and the inner EAP server? In this case the outer EAP
> serve
On Sun, 20 Aug 2023 at 15:58, Alan DeKok wrote:
> On Aug 20, 2023, at 5:15 AM, Alexander Clouter
> wrote:
> >
> > On Fri, 18 Aug 2023, at 01:01, Michael Richardson wrote:
> >> I'm not sure it's sane to use EAP-TLS for Inner method myself.
> >
> > If you mean in the general sense, I can imagine p
On Sun, 20 Aug 2023 at 12:09, Alexander Clouter
wrote:
> On Thu, 17 Aug 2023, at 23:33, Alan DeKok wrote:
> >> If I did run EAP-TLS as an Inner method (whether once or twice), could
> I use resumption?
> >
> > Uh... why didn't anyone mention this before? TEAP is a near-endless
> > source of su
On Thu, 17 Aug 2023 at 22: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 at
> I
On Sat, 19 Aug 2023 at 00:26, Michael Richardson wrote:
> Heikki Vatiainen wrote:
> > Should it be noted that this provisioning method is only available with
> > TLS 1.2 and earlier because the method requires anonymous ciphersuites?
> > It confirms to the reader that this is the in
>>
>> https://www.ietf.org/archive/id/draft-ietf-emu-rfc7170bis-12.html#section-3.5.4
>>
>> Implementations MUST NOT permit resumption for the inner EAP methods
>> such as EAP-TLS. If the user or machine needs to be authenticated,
>> it should use a full authentication method. If the user or mach
On Aug 20, 2023, at 11:01 AM, Vadim Cargatser (vcargats)
wrote:
>
> https://www.ietf.org/archive/id/draft-ietf-emu-rfc7170bis-12.html#section-3.5.4
>
> Implementations MUST NOT permit resumption for the inner EAP methods
> such as EAP-TLS. If the user or machine needs to be authenticated,
> i
https://www.ietf.org/archive/id/draft-ietf-emu-rfc7170bis-12.html#section-3.5.4
Implementations MUST NOT permit resumption for the inner EAP methods
such as EAP-TLS. If the user or machine needs to be authenticated,
it should use a full authentication method. If the user or machine
needs to do r
On Aug 20, 2023, at 5:15 AM, Alexander Clouter wrote:
>
> On Fri, 18 Aug 2023, at 01:01, Michael Richardson wrote:
>> I'm not sure it's sane to use EAP-TLS for Inner method myself.
>
> If you mean in the general sense, I can imagine placing the user credential
> on a hardware key whilst the mac
On Aug 20, 2023, at 5:09 AM, Alexander Clouter wrote:
>
> On Thu, 17 Aug 2023, at 23:33, Alan DeKok wrote:
>>> If I did run EAP-TLS as an Inner method (whether once or twice), could I
>>> use resumption?
>>
>> Uh... why didn't anyone mention this before? TEAP is a near-endless
>> source of s
On Fri, 18 Aug 2023, at 01:01, Michael Richardson wrote:
> I'm not sure it's sane to use EAP-TLS for Inner method myself.
If you mean in the general sense, I can imagine placing the user credential on
a hardware key whilst the machine credential is either a regular software
keychain or even more
On Thu, 17 Aug 2023, at 23:33, Alan DeKok wrote:
>> If I did run EAP-TLS as an Inner method (whether once or twice), could I use
>> resumption?
>
> Uh... why didn't anyone mention this before? TEAP is a near-endless
> source of surprises and corner cases.
In fairness I think you could have th
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 the TLS WG.
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 the TLS WG.
--
Michael Richardson. o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldw
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
Heikki Vatiainen wrote:
>> On Aug 17, 2023, at 5:02 PM, Michael Richardson
>> wrote:
>> > section 3.9.: what is "server unauthenticated provisioning" >
>> (sounds like TEAP-BRSKI?)
>>
>> Yes.
> Should it be noted that this provisioning method is only available with
On Aug 18, 2023, at 1:29 PM, Heikki Vatiainen wrote:
> Good find, looks good. Small fix, though. It's section C.5, not C.2.
Fixed, thanks.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
On Fri, 18 Aug 2023 at 19:57, Alan DeKok wrote:
> On Aug 18, 2023, at 12:47 PM, Heikki Vatiainen
> wrote:
> > Should it be noted that this provisioning method is only available
> > with TLS 1.2 and earlier because the method requires anonymous
> > ciphersuites? It confirms to the reader that thi
On Aug 18, 2023, at 12:47 PM, Heikki Vatiainen
wrote:
> Should it be noted that this provisioning method is only available
> with TLS 1.2 and earlier because the method requires anonymous
> ciphersuites? It confirms to the reader that this is the intended
> case.
How about this:
Note that ser
On Fri, 18 Aug 2023 at 01:34, Alan DeKok wrote:
>
> On Aug 17, 2023, at 5:02 PM, Michael Richardson wrote:
> > section 3.9.: what is "server unauthenticated provisioning"
> > (sounds like TEAP-BRSKI?)
>
> Yes.
Should it be noted that this provisioning method is only available
with TLS 1.2 and
On Aug 17, 2023, at 8:01 PM, Michael Richardson wrote:
> Alan DeKok wrote:
>>> section 2; paragraph 2, uses SHOULD several times without obvious
>>> exceptions. Could be it is MUST?
>
>> I don't think we can mandate that the outer EAP identity is an NAI.
>
> okay, then the exception for the S
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
Emu@iet
On Aug 18, 2023, at 5:46 AM, Vadim Cargatser (vcargats)
wrote:
> In TLS 1.2: the ticket is part of the handshake, so we cannot bind that with
> the successful inner authentication, correct?
Yes. However, RFC 9190 goes into detail about "don't send tickets until
after authentication has comp
Regarding resumptions:
>>> If I did run EAP-TLS as an Inner method (whether once or twice), could
>>> I use resumption?
>> Uh... why didn't anyone mention this before? TEAP is a near-endless
>> source of surprises and corner cases.
> I'm not sure it's sane to use EAP-TLS for Inn
Alan DeKok wrote:
>> section 2; paragraph 2, uses SHOULD several times without obvious
>> exceptions. Could be it is MUST?
> I don't think we can mandate that the outer EAP identity is an NAI.
okay, then the exception for the SHOULD needs text.
>> Figure 2: should TLV Encaps
On Aug 17, 2023, at 5:02 PM, Michael Richardson wrote:
> Some people might find this URL useful:
> https://author-tools.ietf.org/diff?doc_1=RFC7170&doc_2=draft-ietf-emu-rfc7170bis%2F
The diff is surprisingly good.
> Reading the document from top-to-bottom for the first time in awhile (to do
>
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 at IETF
Some people might find this URL useful:
https://author-tools.iet
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 at
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 at IETF
> 117. With post-117 changes incorporated, now's seems like t
Folks,
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 at IETF 117. With
post-117 changes incorporated, now's seems like the time for the WGLC to
38 matches
Mail list logo
