On Mar 11, 2022, at 5:53 AM, Karri Huhtanen
wrote:
> Heikki clarified that this was about the phase1 so the use case in my
> previous email and below does not apply.
Yes. TLS 1.3 encrypts the client certificate, so there's no need to "hide"
EAP-TLS inside of another EAP method.
It probab
On 11.3.2022 9.38, Karri Huhtanen wrote:
On 4.3.2022 21.44, Alan DeKok wrote:
On Mar 4, 2022, at 1:48 PM, Heikki Vatiainen
wrote:
Would it be useful to clarify the use of protected success
indication, TLS application data 0x00, with resumption. I'm mainly
thinking of EAP-TTLS which can end re
On 4.3.2022 21.44, Alan DeKok wrote:
On Mar 4, 2022, at 1:48 PM, Heikki Vatiainen wrote:
Would it be useful to clarify the use of protected success indication, TLS
application data 0x00, with resumption. I'm mainly thinking of EAP-TTLS which
can end resumption very quickly. For example, this
On Mon, 7 Mar 2022 at 17:45, Hannes Tschofenig
wrote:
> Maybe it is a terminology issue but TLS at least requires
> server-authentication.
>
Terminology issue, I think. By "only client certificate" I'm thinking of
what a client needs to do to authenticate. The use of server-authentication
with s
Maybe it is a terminology issue but TLS at least requires server-authentication.
From: Emu On Behalf Of Heikki Vatiainen
Sent: Monday, March 7, 2022 2:41 PM
To: Alan DeKok
Cc: EMU WG
Subject: Re: [Emu] Working Group Last Call for TLS-based EAP types and TLS 1.3
On Fri, 4 Mar 2022 at 21:44
On Mar 7, 2022, at 8:40 AM, Heikki Vatiainen wrote:
> I suggest for this document that we just forbid the case of using only a
> client certificate with TTLS.
>
> No objection from me - and it now appears to be in draft version -05. While
> there may have been client software that supported t
On Fri, 4 Mar 2022 at 21:44, Alan DeKok wrote:
> I would argue that EAP-TTLS with only a client certificate doesn't make
> sense. I'm not sure why it's in RFC 5281. If you want to only use a
> client certificate, you should just use EAP-TLS.
>
> I suggest for this document that we just for
On Mar 4, 2022, at 1:48 PM, Heikki Vatiainen wrote:
> Would it be useful to clarify the use of protected success indication, TLS
> application data 0x00, with resumption. I'm mainly thinking of EAP-TTLS which
> can end resumption very quickly. For example, this EAP-TTLS resumption
> sequence di
On Fri, 18 Feb 2022 at 19:18, Joseph Salowey wrote:
This is a working group last call for TLS-based EAP types and TLS 1.3. The
> document is available here:
> https://datatracker.ietf.org/doc/draft-ietf-emu-tls-eap-types/
>
> Please review the document and provide comments by March 4, 2022
>
Woul
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.org/mailm
Hi to all,
I have found some small typos.
Section 2.4:
> There no "context_value" ([RFC8446] Section 7.5) passed to the TLS-
> Exporter function.
I suppose an "is" is missing.
Section 3:
At the end of the 6th paragraph
> completely bypass the "inner tunnel" authentication
a dot is missing
On Feb 21, 2022, at 4:26 AM, Oleg Pekar wrote:
> 1) Section: 2.1. Key Derivation
>When talking about EAP types "Type = value of the EAP Method type" suggest
> providing an example of a Type here so it will be clear what is it about for
> the rest of the document (e.g. for PEAP Type is 0x19)
Here are my two cents:
1) Section: 2.1. Key Derivation
When talking about EAP types "Type = value of the EAP Method type"
suggest providing an example of a Type here so it will be clear what is it
about for the rest of the document (e.g. for PEAP Type is 0x19)
2) Here TLS-Exporter function is
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/listinfo/e
> On Feb 19, 2022, at 8:57 AM, Alan DeKok wrote:
>
>> - The MAC function in section 2.2 is not defined. I assume it should be
>> HMAC. Suggestion:
>>
>> OLD
>> For TLS 1.3, the hash function used is the same as the
>> ciphersuite hash function negotiated for HKDF in the key schedule,
On Feb 19, 2022, at 3:44 AM, John Mattsson
wrote:
> Comments:
>
> - The MAC function in section 2.2 is not defined. I assume it should be HMAC.
> Suggestion:
>
> OLD
> For TLS 1.3, the hash function used is the same as the
> ciphersuite hash function negotiated for HKDF in the ke
"ciphersuite" (TLS uses the spelling cipher suite)
"NewSessionTicketMessage" (NEW: NewSessionTicket message)
Cheers,
John
From: Emu on behalf of Joseph Salowey
Date: Friday, 18 February 2022 at 18:19
To: EMU WG
Subject: [Emu] Working Group Last Call for TLS-based EA
This is a working group last call for TLS-based EAP types and TLS 1.3. The
document is available here:
https://datatracker.ietf.org/doc/draft-ietf-emu-tls-eap-types/
Please review the document and provide comments by March 4, 2022
Thanks,
Joe and Mohit
___
18 matches
Mail list logo
