Hi Michael,
Thanks for the question. I am objecting to the mandatory use of OCSP for TLS
1.3 in EAP-TLS.
I am fine with having it optional.
Mbed TLS is used in implementations of EAP-TLS and we have received little
interest in OCSP support. The interest is so low that the proposed code was
Hi to all,
as an operator of a EAP-TLS server for eduroam at the University Bremen
I just want to give some of my thoughts here, feel free to read or
ignore them ;)
The eduroam environment is heavily used for BYOD, so we don't have any
opportunity to change certificates via a Device Management.
The Authority-ID TLV is used by the client to identify the TEAP server it
is talking to. If the same client talks to more than one TEAP server - it
can keep PACs or cached data from all of them identified by
the Authority-ID. If we make it optional in TEAP start message but keep
mandatory in
+1. How does anyone even do OCSP without having first gotten onto the network?
Eliot
> On 21 Oct 2020, at 11:02, Hannes Tschofenig wrote:
>
> Hi all,
>
> this draft mandates OCSCP stapling (for use with TLS 1.3 in EAP-TLS) and I
> believe this is a problem for implementations. This extra
On Thu, Oct 22, 2020 at 6:59 AM Oleg Pekar
wrote:
> Hi all,
> Speaking about both errata 5127 and 5128, I think we need to align all key
> derivation calls in TEAP RFC with the same rule/format to make the RFC
> easier to understand. This can be achieved by introducing a unified single
> PRF
The proposal is aligned with previously discussed. One small wording I
would change is:
Section 4.2.13 says:
It MUST be included with the Intermediate-Result TLV to perform
cryptographic binding after each successful EAP authentication method in a
sequence of >>>one or more<<< EAP methods, before
My concern with this proposal of defining a new KDF is that it is a clear
breaking change to any implementation that may exist.
In my opinion such a change would be fine if we want to bump some version
numbers - maybe the TEAP version number has to be bumped, or maybe this can be
achieved
On Oct 22, 2020, at 10:12 AM, Jorge Vergara
wrote:
>
> My concern with this proposal of defining a new KDF is that it is a clear
> breaking change to any implementation that may exist.
I am wary of breaking existing and deployed implementations.
> In my opinion such a change would be fine
Hi all,
Speaking about both errata 5127 and 5128, I think we need to align all key
derivation calls in TEAP RFC with the same rule/format to make the RFC
easier to understand. This can be achieved by introducing a unified single
PRF function that will be called from all the relevant RFC locations.
On Thu, Oct 22, 2020 at 9:29 AM Oleg Pekar
wrote:
> I agree that changing the KDF is harmful to existing implementations.
> However, if I understood correctly, Joe's suggestion for IMCK[j] also
> breaks the existing implementation. I still see that we can define a
> unified KDF by changing the
>[Joe] This is the one we have not discussed yet. This derivation is also
>ambiguous. THis section does not reference 5295. It's not clear if the
>original intent was to include the length in the hash or not. I think there
>are a few interpretations:
>
>1. TLS-PRF(S-IMCK[j], "Session Key
I agree that changing the KDF is harmful to existing implementations.
However, if I understood correctly, Joe's suggestion for IMCK[j] also
breaks the existing implementation. I still see that we can define a
unified KDF by changing the API in the RFC but with the same harm to the
existing
>No, Microsoft implements number 1 of Joe’s presented options. That is -
P_(S-IMCK[j], "Session Key Generating Function").
>This follows the same pattern as the errata we are discussion. I am very
surprised to hear that Cisco’s implementation may be different. Oleg, could
you please double
Hannes Tschofenig wrote:
> Thanks for the question. I am objecting to the mandatory use of OCSP for
TLS 1.3 in EAP-TLS.
> I am fine with having it optional.
okay, so it's not about the stapling, at all for you, it's about the OCSP
itself.
--
Michael Richardson. o O ( IPv6 IøT
On Thu, Oct 22, 2020 at 8:08 AM Eliot Lear
wrote:
> +1. How does anyone even do OCSP without having first gotten onto the
> network?
>
>
[Joe] THat is what OCSP stapling is supposed to solve since the OCSP
messages are sent in the TLS handshake. I believe there are some EAP-TLS
Joseph Salowey wrote:
> On Thu, Oct 22, 2020 at 8:08 AM Eliot Lear
> wrote:
>> +1. How does anyone even do OCSP without having first gotten onto the
>> network?
> [Joe] THat is what OCSP stapling is supposed to solve since the OCSP
> messages are sent in the TLS
16 matches
Mail list logo
