On Mon, 9 Jan 2023, at 14:11, Heikki Vatiainen wrote:
>> On a related note, whilst we are here, it does raise the question on how we
>> got:
>>
>> "...the length is 64 octets..." and "First 32 octets of TLS-PRF(...)"
>>
>> The '0x00 || 0x40' (64 network order 16bit length concatenation) looks
On Mon, 9 Jan 2023 at 10:57, Alexander Clouter
wrote:
Problem is this section has the instruction "generate 64 bytes, use the
> first 32..." and after personally getting tripped up[1] on the different
> though used with TLS-Exporter which for TLSv1.3 now generates wildly
> different outputs
On Mon, 9 Jan 2023, at 03:34, Joseph Salowey wrote:
> The definition of the TLS-PRF is given in 5246 as:
>
> PRF(secret, label, seed) = P_(secret, label | seed)
>
> This construction only defines 3 parameters and does not define a length. I
> don't think current implementations include the
I think we still have an open issue with 5128. The following resolutions
differ from what is currently in RFC7170bis. Please review the text
changes below and indicate if it aligns with implementation and
discussion.
Thanks,
Joe
The definition of the TLS-PRF is given in 5246 as:
PRF(secret,
According to the discussion in the interim last week and previous
discussions the resolution of errata 5127 should be as below. Please
review the text change below and indicate if it aligns with discussion and
implementation. It is intended that it matches the current draft of RFC7170bis
draft
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
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
Errata 5767: https://www.rfc-editor.org/errata/eid5767
Status: Verified
Revision:
Section 3.3.1 says:
EAP method messages are carried within EAP-Payload TLVs defined in
Section 4.2.10. If more than one method is going to be executed in
the tunnel, then upon method completion, the
I'll be posting proposed errata revisions for a short, 1 week, final review
before sending it off to the Area Director (Roman) who has the
responsibility of the final action. For more information how errata are
handled and the please see [1].
Please take a little time to review the errata
