I think we have agreement on what the derivation would be now it's a matter
of clearly describing it. Here is a proposal:
IMCK[j] = the first 60 bytes of TLS-PRF(S-IMCK[j-1], "Inner Methods
Compound Keys", IMSK[j])
where "|" denotes concatenation and the TLS-PRF is defined in
There were so many messages in this thread that I'm not going try to
address each point separately, but I think in general I do agree with
the comments and it looks like all the identified implementation are
doing the same thing here..
I don't see any strong need to encode the output length of
>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
>[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
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
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
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
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
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
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.
(I accidentally dropped this list from the conversation)
On Wed, Oct 21, 2020 at 4:48 PM Jorge Vergara
wrote:
> >[Joe] Yes this is a concern and I think your interpretation of the
> current document is also valid. There may be more than one
> implementation. So what you implemented was:
>
> >
In theory I agree this is a possible resolution. However, this doesn’t match
any of the current TEAP implementations that I am aware of. Perhaps Oleg can
weigh in as well in terms of what he’s seen.
I believe all current implementations treat 60 as the desired output length
without treating as
Errata 5128: https://www.rfc-editor.org/errata/eid5128
Proposed State: Verified
Revision:
Section 5.2. says
IMCK[j] = TLS-PRF(S-IMCK[j-1], "Inner Methods Compound Keys",
IMSK[j], 60)
It should say:
IMCK[j] = TLS-PRF(S-IMCK[j-1], "Inner Methods Compound Keys", IMSK[j] | 60)
13 matches
Mail list logo
