subject:"\[Emu\] Proposed resolution for TEAP errata for 5128"

Re: [Emu] Proposed resolution for TEAP errata for 5128

2020-10-23 Thread Joseph Salowey

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
  [RFC5246] as

PRF(secret, label, seed) = P_(secret, label | seed).

 the secret is S-IMCK[j-1],  the label is
 "Inner Methods Compound Keys" consisting of the ASCII value for the
 label "Inner Methods Compound Keys" (without quotes),  the seed
 consists IMSK[j].

MSK = the first 64 bytes of TLS-PRF(S-IMCK[j], "Session Key Generating
Function")
EMSK = the first 64 bytes of TLS-PRF(S-IMCK[j], "Extended Session Key
Generating Function")

  where "|" denotes concatenation and the TLS-PRF is defined in
  [RFC5246] as

PRF(secret, label, seed) = P_(secret, label | seed).

 The secret is S-IMCK[j-1]  where j is the number of the last
successfully
 executed inner EAP method.  The label is is the ASCII value for the
 string without quotes.  The seed is empty (0 length) and omitted from
 the derivation.

On Fri, Oct 23, 2020 at 9:58 AM Jouni Malinen  wrote:

> 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 the PRF into
> the input data especially since we are using hardcoded output lengths in
> these cases. That said, I'm not against keeping it there for the IMSK
> derivation since that particular case seemed to be explicitly defined as
> using a 2-octet field in network byte order (and all the known
> implementations doing exactly that). IMHO, the other cases should not be
> modified to try to be consistent with this.
>
> While I do understand the benefits of having an explicit fixed delimiter
> "\0" between the label and seed to enforce unique interpretation if two
> labels were to have same prefix, I don't see that as a critical issue in
> any of the instances used within TEAP due to no such common prefix case
> exist nor do we even use TLS-PRF with the same secret/key. Furthermore,
> RFC 5246 does not mandate or even discuss such delimiter.
>
> There is no need to convert an empty seed to 0x00 or anything else.
> TLS-PRF can be used with secret=something, label=ASCII string,
> seed=0-length data) without issues.
>
> If we want to define a new TEAP-PRF() function, I'd prefer it to be
> using consistent terminology with TLS-PRF in RFC 5246 (and well, to
> extend possible, also be as consistent as can be with the TLS-Exporter
> use in RFC 8446). This would also mean not trying to enforce some 0x00
> delimiter or length in context data. At its simplest and only with TLS
> v1.2 in mind for clarity here, this could look something like
>
> TEAP-PRF(secret, label, seed, output length) =
> PRF(secret, label, seed) outputting "output length" octets
>
> label = ASCII string, no "\x0" termination
> seed = arbitrary binary data (including possibility of 0-length empty
> case)
>
> With this, we would have following:
> IMSK = First 32 octets of TEAP-PRF(EMSK, "teapbind...@ietf.org", 0x00 |
> 0x00 | 0x40, 64)
> IMCK[j] = TEAP-PRF(S-IMCK[j-1], "Inner Methods Compound Keys", IMSK[j], 60)
> MSK = TEAP-PRF(S-IMCK[j], "Session Key Generating Function", , 64)
> EMSK = TEAP-PRF(S-IMCK[j], "Extended Session Key Generating Function",
> , 64)
>
> RFC 5295 rules about EMSK use for USRK/DSRK applies for the first one of
> these and it does seem to give justification for the seed to have "\0"
> and "length" (as 2-octet unsigned integer in network byte order). While
> one could claim that the rules for DSUSRK derivation applies to those
> other instances and as such, would require 0x00 and length to be added
> around the seed shown above, I'd note that there does not seem to be any
> MUST statement about that in RFC 5295 and as such, I think the versions
> described above (and the ones used in known implementations today) seem
> to be justifiable especially taken into account the unique label string
> prefixes and fixed length of output data.
>
> --
> Jouni MalinenPGP id EFC895FA
>
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] Proposed resolution for TEAP errata for 5128

2020-10-23 Thread Jouni Malinen

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 the PRF into
the input data especially since we are using hardcoded output lengths in
these cases. That said, I'm not against keeping it there for the IMSK
derivation since that particular case seemed to be explicitly defined as
using a 2-octet field in network byte order (and all the known
implementations doing exactly that). IMHO, the other cases should not be
modified to try to be consistent with this.

While I do understand the benefits of having an explicit fixed delimiter
"\0" between the label and seed to enforce unique interpretation if two
labels were to have same prefix, I don't see that as a critical issue in
any of the instances used within TEAP due to no such common prefix case
exist nor do we even use TLS-PRF with the same secret/key. Furthermore,
RFC 5246 does not mandate or even discuss such delimiter.

There is no need to convert an empty seed to 0x00 or anything else.
TLS-PRF can be used with secret=something, label=ASCII string,
seed=0-length data) without issues.

If we want to define a new TEAP-PRF() function, I'd prefer it to be
using consistent terminology with TLS-PRF in RFC 5246 (and well, to
extend possible, also be as consistent as can be with the TLS-Exporter
use in RFC 8446). This would also mean not trying to enforce some 0x00
delimiter or length in context data. At its simplest and only with TLS
v1.2 in mind for clarity here, this could look something like

TEAP-PRF(secret, label, seed, output length) =
PRF(secret, label, seed) outputting "output length" octets

label = ASCII string, no "\x0" termination
seed = arbitrary binary data (including possibility of 0-length empty
case)

With this, we would have following:
IMSK = First 32 octets of TEAP-PRF(EMSK, "teapbind...@ietf.org", 0x00 |
0x00 | 0x40, 64)
IMCK[j] = TEAP-PRF(S-IMCK[j-1], "Inner Methods Compound Keys", IMSK[j], 60)
MSK = TEAP-PRF(S-IMCK[j], "Session Key Generating Function", , 64)
EMSK = TEAP-PRF(S-IMCK[j], "Extended Session Key Generating Function",
, 64)

RFC 5295 rules about EMSK use for USRK/DSRK applies for the first one of
these and it does seem to give justification for the seed to have "\0"
and "length" (as 2-octet unsigned integer in network byte order). While
one could claim that the rules for DSUSRK derivation applies to those
other instances and as such, would require 0x00 and length to be added
around the seed shown above, I'd note that there does not seem to be any
MUST statement about that in RFC 5295 and as such, I think the versions
described above (and the ones used in known implementations today) seem
to be justifiable especially taken into account the unique label string
prefixes and fixed length of output data.

-- 
Jouni MalinenPGP id EFC895FA

___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] Proposed resolution for TEAP errata for 5128

2020-10-22 Thread Oleg Pekar

>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 check? I have just double checked our

>implementation. Since our implementations interop, I assume we must have
the same implementation.



Jorge, thanks for pointing that out. Cisco also implements option number 1
from above. I referenced to EAP-FAST implementation by mistake, sorry.


So, not to harm at least two implementations, all we can do for errata
5127, 5128 - is just to change the wording to be more clear, removing
ambiguity.

On Thu, Oct 22, 2020 at 7:58 PM Jorge Vergara 
wrote:

> >[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 Generating Function")  iterated to
> generate 64 bytes = P_hash(S-IMCK[j], "Session Key Generating Function”)
>
> >2. TLS-PRF(S-IMCK[j], "Session Key Generating Function", 64)  iterated
> to generate 64 bytes = P_hash(S-IMCK[j], "Session Key Generating Function”
> | 0x00 | 0x40)
>
> >3. (Follow 5295 parameters) TLS-PRF(S-IMCK[j], "Session Key Generating
> Function", "\0" | 64) = P_hash(S-IMCK[j], "Session Key Generating
> Function” | 0x00 | 0x00 | 0x40)
>
> >
>
> >I think 1 or 2 is what was probably originally intended, however it seems
> that 3 is what has been implemented.  Do we have agreement on this is what
> current implementations do?
>
>
>
> 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 check? I have just double checked our implementation.
> Since our implementations interop, I assume we must have the same
> implementation.
>
>
>
> Jorge Vergara
>
>
>
>
>
> *From:* Joseph Salowey 
> *Sent:* Thursday, October 22, 2020 9:53 AM
> *To:* Oleg Pekar 
> *Cc:* EMU WG ; Jorge Vergara ;
> Jouni Malinen 
> *Subject:* Re: Proposed resolution for TEAP errata for 5128
>
>
>
>
>
>
>
> 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 API in the RFC but with the same harm to the
> existing implementation in IMCK[j] as in both proposals:
>
>
>
> TEAP-PRF (secret, key label, optional data, length) = TLS-PRF(secret, key
> label | 0x00 | optional data, length)
>
> Joe, thanks for pointing out that RFC 5295 doesn't specify that a 0x00 is
> used to represent no optional data, that was just my mistake.
>
>
>
> IMSK:
>
> Current Microsoft and Cisco implementation: P_hash(EMSK, "
> teapbind...@ietf.org" | 0x00 | 0x00 | 0x40)
>
> Joe's proposal: P_hash(EMSK, "teapbind...@ietf.org" | 0x00 | 0x00 |
> 0x40), the same, just the API correction
>
> Unified KDF proposal: TEAP-PRF(EMSK, "teapbind...@ietf.org",  data>, 64) = P_hash(EMSK, "teapbind...@ietf.org" | 0x00 | 0x00 | 0x40)
>
> --- no implementation change
>
>
>
> IMCK[j]:
>
> Current Microsoft and Cisco implementation: P_hash(S-IMCK[j-1], "Inner
> Methods Compound Keys” | IMSK[j])
>
> Joe's proposal: P_hash(S-IMCK[j-1], "Inner Methods Compound Keys" |
> IMSK[j] | 0x00 | 0x3C)
>
> Unified KDF proposal: TEAP-PRF(S-IMCK[j-1], "Inner Methods Compound Keys",
> IMSK[j], 60) = P_hash(S-IMCK[j-1], "Inner Methods Compound Keys" | IMSK[j]
> | 0x00 | 0x3C)
>
> --- implementation change
>
>
>
> [Joe] That was my initial proposal, but based on Jorge's comment it is
> modified to:
>
>
> IMCK[j] = TLS-PRF(S-IMCK[j-1], "Inner Methods Compound Keys", IMSK[j])
> to generate a length of 60 bytes
>
> IMCK[j] = P_hash(S-IMCK[j-1], "Inner Methods Compound Keys” | IMSK[j])
>
>
>
>
>
> MSK:
>
> Current Microsoft and Cisco implementation: P_hash(S-IMCK[j], "Session Key
> Generating Function” | 0x00 | 0x00 | 0x40)
>
> Unified KDF proposal: TEAP-PRF(S-IMCK[j], "Session Key Generating
> Function”, , 64) = P_hash(S-IMCK[j], "Session Key
> Generating Function” | 0x00 | 0x00 | 0x40)
>
> --- no implementation change
>
>
>
> [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 Generating Function")  iterated to
> generate 64 bytes = P_hash(S-IMCK[j], "Session Key Generating Function”)
>
>

Re: [Emu] Proposed resolution for TEAP errata for 5128

2020-10-22 Thread Jorge Vergara

>[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 Generating Function")  iterated to generate 
>64 bytes = P_hash(S-IMCK[j], "Session Key Generating Function”)
>2. TLS-PRF(S-IMCK[j], "Session Key Generating Function", 64)  iterated to 
>generate 64 bytes = P_hash(S-IMCK[j], "Session Key Generating Function” | 0x00 
>| 0x40)
>3. (Follow 5295 parameters) TLS-PRF(S-IMCK[j], "Session Key Generating 
>Function", "\0" | 64) = P_hash(S-IMCK[j], "Session Key Generating Function” | 
>0x00 | 0x00 | 0x40)
>
>I think 1 or 2 is what was probably originally intended, however it seems that 
>3 is what has been implemented.  Do we have agreement on this is what current 
>implementations do?

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 check? I have just double checked our implementation. Since our 
implementations interop, I assume we must have the same implementation.

Jorge Vergara

From: Joseph Salowey 
Sent: Thursday, October 22, 2020 9:53 AM
To: Oleg Pekar 
Cc: EMU WG ; Jorge Vergara ; Jouni 
Malinen 
Subject: Re: Proposed resolution for TEAP errata for 5128

On Thu, Oct 22, 2020 at 9:29 AM Oleg Pekar 
mailto:oleg.pekar.2...@gmail.com>> 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 API in the RFC but with the same harm to the existing 
implementation in IMCK[j] as in both proposals:

TEAP-PRF (secret, key label, optional data, length) = TLS-PRF(secret, key label 
| 0x00 | optional data, length)
Joe, thanks for pointing out that RFC 5295 doesn't specify that a 0x00 is used 
to represent no optional data, that was just my mistake.

IMSK:
Current Microsoft and Cisco implementation: P_hash(EMSK, 
"teapbind...@ietf.org" | 0x00 | 0x00 | 0x40)
Joe's proposal: P_hash(EMSK, 
"teapbind...@ietf.org" | 0x00 | 0x00 | 0x40), the 
same, just the API correction
Unified KDF proposal: TEAP-PRF(EMSK, 
"teapbind...@ietf.org", , 64) = 
P_hash(EMSK, "teapbind...@ietf.org" | 0x00 | 0x00 
| 0x40)
--- no implementation change

IMCK[j]:
Current Microsoft and Cisco implementation: P_hash(S-IMCK[j-1], "Inner Methods 
Compound Keys” | IMSK[j])
Joe's proposal: P_hash(S-IMCK[j-1], "Inner Methods Compound Keys" | IMSK[j] | 
0x00 | 0x3C)
Unified KDF proposal: TEAP-PRF(S-IMCK[j-1], "Inner Methods Compound Keys", 
IMSK[j], 60) = P_hash(S-IMCK[j-1], "Inner Methods Compound Keys" | IMSK[j] | 
0x00 | 0x3C)
--- implementation change

[Joe] That was my initial proposal, but based on Jorge's comment it is modified 
to:

IMCK[j] = TLS-PRF(S-IMCK[j-1], "Inner Methods Compound Keys", IMSK[j])  to 
generate a length of 60 bytes
IMCK[j] = P_hash(S-IMCK[j-1], "Inner Methods Compound Keys” | IMSK[j])

MSK:
Current Microsoft and Cisco implementation: P_hash(S-IMCK[j], "Session Key 
Generating Function” | 0x00 | 0x00 | 0x40)
Unified KDF proposal: TEAP-PRF(S-IMCK[j], "Session Key Generating Function”, 
, 64) = P_hash(S-IMCK[j], "Session Key Generating Function” | 
0x00 | 0x00 | 0x40)
--- no implementation change

[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 Generating Function")  iterated to generate 
64 bytes = P_hash(S-IMCK[j], "Session Key Generating Function”)
2. TLS-PRF(S-IMCK[j], "Session Key Generating Function", 64)  iterated to 
generate 64 bytes = P_hash(S-IMCK[j], "Session Key Generating Function” | 0x00 
| 0x40)
3. (Follow 5295 parameters) TLS-PRF(S-IMCK[j], "Session Key Generating 
Function", "\0" | 64) = P_hash(S-IMCK[j], "Session Key Generating Function” | 
0x00 | 0x00 | 0x40)

I think 1 or 2 is what was probably originally intended, however it seems that 
3 is what has been implemented.  Do we have agreement on this is what current 
implementations do?

Jorge, please correct me if I misinterpret the Microsoft implementation.

On Thu, Oct 22, 2020 at 6:55 PM Joseph Salowey 
mailto:j...@salowey.net>> wrote:

On Thu, Oct 22, 2020 at 6:59 AM Oleg Pekar 
mailto:oleg.pekar.2...@gmail.com>> wrote:
Hi all,
Speaking about both errata 5127 and 5128, I think we need to align all key 
derivation calls in TEAP RFC with

Re: [Emu] Proposed resolution for TEAP errata for 5128

2020-10-22 Thread Joseph Salowey

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 API in the RFC but with the same harm to the
> existing implementation in IMCK[j] as in both proposals:
>
> TEAP-PRF (secret, key label, optional data, length) = TLS-PRF(secret, key
> label | 0x00 | optional data, length)
> Joe, thanks for pointing out that RFC 5295 doesn't specify that a 0x00 is
> used to represent no optional data, that was just my mistake.
>
> IMSK:
> Current Microsoft and Cisco implementation: P_hash(EMSK, "
> teapbind...@ietf.org" | 0x00 | 0x00 | 0x40)
> Joe's proposal: P_hash(EMSK, "teapbind...@ietf.org" | 0x00 | 0x00 |
> 0x40), the same, just the API correction
> Unified KDF proposal: TEAP-PRF(EMSK, "teapbind...@ietf.org",  data>, 64) = P_hash(EMSK, "teapbind...@ietf.org" | 0x00 | 0x00 | 0x40)
> --- no implementation change
>
> IMCK[j]:
> Current Microsoft and Cisco implementation: P_hash(S-IMCK[j-1], "Inner
> Methods Compound Keys” | IMSK[j])
> Joe's proposal: P_hash(S-IMCK[j-1], "Inner Methods Compound Keys" |
> IMSK[j] | 0x00 | 0x3C)
> Unified KDF proposal: TEAP-PRF(S-IMCK[j-1], "Inner Methods Compound Keys",
> IMSK[j], 60) = P_hash(S-IMCK[j-1], "Inner Methods Compound Keys" | IMSK[j]
> | 0x00 | 0x3C)
> --- implementation change
>

[Joe] That was my initial proposal, but based on Jorge's comment it is
modified to:

IMCK[j] = TLS-PRF(S-IMCK[j-1], "Inner Methods Compound Keys", IMSK[j])  to
generate a length of 60 bytes
IMCK[j] = P_hash(S-IMCK[j-1], "Inner Methods Compound Keys” | IMSK[j])


>
> MSK:
> Current Microsoft and Cisco implementation: P_hash(S-IMCK[j], "Session Key
> Generating Function” | 0x00 | 0x00 | 0x40)
> Unified KDF proposal: TEAP-PRF(S-IMCK[j], "Session Key Generating
> Function”, , 64) = P_hash(S-IMCK[j], "Session Key
> Generating Function” | 0x00 | 0x00 | 0x40)
> --- no implementation change
>
> [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 Generating Function")  iterated to
generate 64 bytes = P_hash(S-IMCK[j], "Session Key Generating Function”)
2. TLS-PRF(S-IMCK[j], "Session Key Generating Function", 64)  iterated to
generate 64 bytes = P_hash(S-IMCK[j], "Session Key Generating Function” |
0x00 | 0x40)
3. (Follow 5295 parameters) TLS-PRF(S-IMCK[j], "Session Key Generating
Function", "\0" | 64) = P_hash(S-IMCK[j], "Session Key Generating Function”
| 0x00 | 0x00 | 0x40)

I think 1 or 2 is what was probably originally intended, however it seems
that 3 is what has been implemented.  Do we have agreement on this is what
current implementations do?





> Jorge, please correct me if I misinterpret the Microsoft implementation.
>
> On Thu, Oct 22, 2020 at 6:55 PM Joseph Salowey  wrote:
>
>>
>>
>> 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 function that will be called from all the relevant RFC locations. For
>>> me it sounds better than if we align just part of KDF calls with RFC 5295
>>> (where the output length is included into seed). Also: in some KDF calls we
>>> do have optional data and in some no. This could be also unified.
>>>
>>> [Joe] I don't think this was the original intent of the document.  The
>> IMSK derivation referenced 5295 while the others just reference the TLS
>> PRF.  I think to unify them would require a document update and I'm not
>> sure what we would gain especially if we have implementations that do
>> this.
>>
>>
>>> So I would suggest introducing:
>>> TEAP-PRF (secret, key label, optional data, length) = TLS-PRF(secret,
>>> key label | 0x00 | optional data, length)
>>> where a single byte 0x00 is used for no optional data, length is a
>>> 2-octet unsigned integer in network byte order.
>>>
>>> [Joe] I don't think that 5295 specifies that a 0x00 is used to represent
>> no optional data.  Did you see this in the spec? It may be ambiguous, but I
>> think the intent is that optional data is just omitted if it is not
>> provided.
>>
>>
>>
>>> Then:
>>> IMSK = First 32 octets of TEAP-PRF(EMSK, "teapbind...@ietf.org", 64) =
>>> TLS-PRF(EMSK, "teapbind...@ietf.org" | 0x00 | 0x00 | 0x00 | 0x40)
>>> IMCK[j] = TEAP-PRF(S-IMCK[j-1], "Inner Methods Compound Keys", IMSK[j],
>>> 60) = TLS-PRF(S-IMCK[j-1], "Inner Methods Compound Keys" | 0x00 | IMSK[j] |
>>> 0x00 | 0x3C)
>>> MSK = TEAP-PRF(S-IMCK[j], "Session Key Generating Function”, 64) =
>>>

Re: [Emu] Proposed resolution for TEAP errata for 5128

2020-10-22 Thread Oleg Pekar

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 implementation in IMCK[j] as in both proposals:

TEAP-PRF (secret, key label, optional data, length) = TLS-PRF(secret, key
label | 0x00 | optional data, length)
Joe, thanks for pointing out that RFC 5295 doesn't specify that a 0x00 is
used to represent no optional data, that was just my mistake.

IMSK:
Current Microsoft and Cisco implementation: P_hash(EMSK, "
teapbind...@ietf.org" | 0x00 | 0x00 | 0x40)
Joe's proposal: P_hash(EMSK, "teapbind...@ietf.org" | 0x00 | 0x00 | 0x40),
the same, just the API correction
Unified KDF proposal: TEAP-PRF(EMSK, "teapbind...@ietf.org", , 64) = P_hash(EMSK, "teapbind...@ietf.org" | 0x00 | 0x00 | 0x40)
--- no implementation change

IMCK[j]:
Current Microsoft and Cisco implementation: P_hash(S-IMCK[j-1], "Inner
Methods Compound Keys” | IMSK[j])
Joe's proposal: P_hash(S-IMCK[j-1], "Inner Methods Compound Keys" | IMSK[j]
| 0x00 | 0x3C)
Unified KDF proposal: TEAP-PRF(S-IMCK[j-1], "Inner Methods Compound Keys",
IMSK[j], 60) = P_hash(S-IMCK[j-1], "Inner Methods Compound Keys" | IMSK[j]
| 0x00 | 0x3C)
--- implementation change

MSK:
Current Microsoft and Cisco implementation: P_hash(S-IMCK[j], "Session Key
Generating Function” | 0x00 | 0x00 | 0x40)
Unified KDF proposal: TEAP-PRF(S-IMCK[j], "Session Key Generating
Function”, , 64) = P_hash(S-IMCK[j], "Session Key
Generating Function” | 0x00 | 0x00 | 0x40)
--- no implementation change

Jorge, please correct me if I misinterpret the Microsoft implementation.

On Thu, Oct 22, 2020 at 6:55 PM Joseph Salowey  wrote:

>
>
> 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 function that will be called from all the relevant RFC locations. For
>> me it sounds better than if we align just part of KDF calls with RFC 5295
>> (where the output length is included into seed). Also: in some KDF calls we
>> do have optional data and in some no. This could be also unified.
>>
>> [Joe] I don't think this was the original intent of the document.  The
> IMSK derivation referenced 5295 while the others just reference the TLS
> PRF.  I think to unify them would require a document update and I'm not
> sure what we would gain especially if we have implementations that do
> this.
>
>
>> So I would suggest introducing:
>> TEAP-PRF (secret, key label, optional data, length) = TLS-PRF(secret, key
>> label | 0x00 | optional data, length)
>> where a single byte 0x00 is used for no optional data, length is a
>> 2-octet unsigned integer in network byte order.
>>
>> [Joe] I don't think that 5295 specifies that a 0x00 is used to represent
> no optional data.  Did you see this in the spec? It may be ambiguous, but I
> think the intent is that optional data is just omitted if it is not
> provided.
>
>
>
>> Then:
>> IMSK = First 32 octets of TEAP-PRF(EMSK, "teapbind...@ietf.org", 64) =
>> TLS-PRF(EMSK, "teapbind...@ietf.org" | 0x00 | 0x00 | 0x00 | 0x40)
>> IMCK[j] = TEAP-PRF(S-IMCK[j-1], "Inner Methods Compound Keys", IMSK[j],
>> 60) = TLS-PRF(S-IMCK[j-1], "Inner Methods Compound Keys" | 0x00 | IMSK[j] |
>> 0x00 | 0x3C)
>> MSK = TEAP-PRF(S-IMCK[j], "Session Key Generating Function”, 64) =
>> TLS-PRF(S-IMCK[j], "Session Key Generating Function" | 0x00 | 0x00 | 0x00 |
>> 0x40)
>> EMSK = TEAP-PRF(S-IMCK[j], ”Extended Session Key Generating Function”,
>> 64) = TLS-PRF(S-IMCK[j], "Extended Session Key Generating Function" | 0x00
>> | 0x00 | 0x00 | 0x40)
>>
>> This may change the existing implementation but will make it more clear -
>> need to create and call just one KDF function.
>>
>> We can remove 0x00 that comes after the key label - while it is required
>> by RFC 5295. But there the key label is also ASCII printable string. Joe,
>> do you remember what was the motivation to put 0x00 after the key label
>> parameter?
>>
>
> [Joe] the null after the key label is to provide a delimiter between the
> key label and optional data.  Since the optional data can be arbitrary
> content the null prevents two different lablels with specially crafted
> optional data from deriving the same key.
>
>
>>
>> Oleg
>>
>>
>> On Thu, Oct 22, 2020 at 2:54 AM Joseph Salowey  wrote:
>>
>>> (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:

 >

 >IMCK[j] = TLS-PRF(S-IMCK[j-1],

Re: [Emu] Proposed resolution for TEAP errata for 5128

2020-10-22 Thread Joseph Salowey

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 function that will be called from all the relevant RFC locations. For
> me it sounds better than if we align just part of KDF calls with RFC 5295
> (where the output length is included into seed). Also: in some KDF calls we
> do have optional data and in some no. This could be also unified.
>
> [Joe] I don't think this was the original intent of the document.  The
IMSK derivation referenced 5295 while the others just reference the TLS
PRF.  I think to unify them would require a document update and I'm not
sure what we would gain especially if we have implementations that do
this.


> So I would suggest introducing:
> TEAP-PRF (secret, key label, optional data, length) = TLS-PRF(secret, key
> label | 0x00 | optional data, length)
> where a single byte 0x00 is used for no optional data, length is a 2-octet
> unsigned integer in network byte order.
>
> [Joe] I don't think that 5295 specifies that a 0x00 is used to represent
no optional data.  Did you see this in the spec? It may be ambiguous, but I
think the intent is that optional data is just omitted if it is not
provided.



> Then:
> IMSK = First 32 octets of TEAP-PRF(EMSK, "teapbind...@ietf.org", 64) =
> TLS-PRF(EMSK, "teapbind...@ietf.org" | 0x00 | 0x00 | 0x00 | 0x40)
> IMCK[j] = TEAP-PRF(S-IMCK[j-1], "Inner Methods Compound Keys", IMSK[j],
> 60) = TLS-PRF(S-IMCK[j-1], "Inner Methods Compound Keys" | 0x00 | IMSK[j] |
> 0x00 | 0x3C)
> MSK = TEAP-PRF(S-IMCK[j], "Session Key Generating Function”, 64) =
> TLS-PRF(S-IMCK[j], "Session Key Generating Function" | 0x00 | 0x00 | 0x00 |
> 0x40)
> EMSK = TEAP-PRF(S-IMCK[j], ”Extended Session Key Generating Function”, 64)
> = TLS-PRF(S-IMCK[j], "Extended Session Key Generating Function" | 0x00 |
> 0x00 | 0x00 | 0x40)
>
> This may change the existing implementation but will make it more clear -
> need to create and call just one KDF function.
>
> We can remove 0x00 that comes after the key label - while it is required
> by RFC 5295. But there the key label is also ASCII printable string. Joe,
> do you remember what was the motivation to put 0x00 after the key label
> parameter?
>

[Joe] the null after the key label is to provide a delimiter between the
key label and optional data.  Since the optional data can be arbitrary
content the null prevents two different lablels with specially crafted
optional data from deriving the same key.


>
> Oleg
>
>
> On Thu, Oct 22, 2020 at 2:54 AM Joseph Salowey  wrote:
>
>> (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:
>>>
>>> >
>>>
>>> >IMCK[j] = TLS-PRF(S-IMCK[j-1], "Inner Methods Compound Keys", IMSK[j])
>>> = P_(S-IMCK[j-1], "Inner Methods Compound Keys" | IMSK[j])
>>>
>>>
>>>
>>> Yes, this is what I implemented. As you mentioned, there are multiple
>>> possible interpretations of this since the TEAP usage is incorrect.
>>> However, my implementation does interop with at least 2 large vendor
>>> implementations. If the implementations were using different calculations
>>> here, the Wi-Fi/Ethernet connections that depend on the MSK would fail. But
>>> since connections work, I can assume we are all using the same
>>> implementation and arriving at the same MSK. Cisco is one of the
>>> implementations that I have tested against which is why I was hoping Oleg
>>> may offer more context as to what he has seen.
>>>
>>>
>>>
>> [Joe] I can hope Jouni can chime in on this as well.  I think the
>> original intent was to not include the length as is your suggestion.
>>
>>
>>
>>> >[Joe] Does the revision in 5167 match you implementation ( I don't
>>> think Jouni's comment changes the underly calculation, just its
>>> representation)?
>>>
>>>
>>>
>>> I have not implemented this portion of the RFC as I found it too unclear
>>> to work with. Thus I can’t comment on what implementations may be doing.
>>> However, I agree with the current revision in 5167 as the most natural
>>> interpretation. If others have implemented this portion of the RFC then
>>> certainly their comments would be welcome.
>>>
>>>
>>> By the way, we’ve dropped the EMU group on our replies here – not sure
>>> if intentional or not.
>>>
>>>
>>>
>>> Jorge Vergara
>>>
>>>
>>>
>>> *From:* Joseph Salowey 
>>> *Sent:* Wednesday, October 21, 2020 4:36 PM
>>> *To:* Jorge Vergara 
>>> *Subject:* Re: Proposed resolution for TEAP errata for 5128
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Wed, Oct 21, 2020 at 3:20 PM Jorge Vergara 
>>> wrote:
>>>
>>> In theory I agree this is a possible

Re: [Emu] Proposed resolution for TEAP errata for 5128

2020-10-22 Thread Alan DeKok

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 if we want to bump some version 
> numbers - maybe the TEAP version number has to be bumped, or maybe this can 
> be achieved solely with the TLV version fields some of the TLVs contain. I 
> haven’t thought about this aspect of too much. But redefining the KDF 
> entirely with no version changes would be disruptive to multiple products.

  TBH, there isn't a lot of point.  We should just document what 
implementations do today.  Then, suggest that everyone move to TLS 1.3, and 
define entirely new derivations there.

  Alan DeKok.

___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] Proposed resolution for TEAP errata for 5128

2020-10-22 Thread Jorge Vergara

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 solely with the TLV version fields some of the TLVs contain. I haven’t 
thought about this aspect of too much. But redefining the KDF entirely with no 
version changes would be disruptive to multiple products.

This leads to a follow-up concern is - if an entirely new KDF were to be 
defined, I believe it should avoid using the TLS 1.2 PRF since it is already 
obsoleted in TLS 1.3.

Jorge Vergara

From: Oleg Pekar 
Sent: Thursday, October 22, 2020 6:59 AM
To: Joseph Salowey 
Cc: EMU WG ; Jorge Vergara ; Jouni 
Malinen 
Subject: Re: Proposed resolution for TEAP errata for 5128

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. For me it 
sounds better than if we align just part of KDF calls with RFC 5295 (where the 
output length is included into seed). Also: in some KDF calls we do have 
optional data and in some no. This could be also unified.

So I would suggest introducing:
TEAP-PRF (secret, key label, optional data, length) = TLS-PRF(secret, key label 
| 0x00 | optional data, length)
where a single byte 0x00 is used for no optional data, length is a 2-octet 
unsigned integer in network byte order.

Then:
IMSK = First 32 octets of TEAP-PRF(EMSK, 
"teapbind...@ietf.org", 64) = TLS-PRF(EMSK, 
"teapbind...@ietf.org" | 0x00 | 0x00 | 0x00 | 0x40)
IMCK[j] = TEAP-PRF(S-IMCK[j-1], "Inner Methods Compound Keys", IMSK[j], 60) = 
TLS-PRF(S-IMCK[j-1], "Inner Methods Compound Keys" | 0x00 | IMSK[j] | 0x00 | 
0x3C)
MSK = TEAP-PRF(S-IMCK[j], "Session Key Generating Function”, 64) = 
TLS-PRF(S-IMCK[j], "Session Key Generating Function" | 0x00 | 0x00 | 0x00 | 
0x40)
EMSK = TEAP-PRF(S-IMCK[j], ”Extended Session Key Generating Function”, 64) = 
TLS-PRF(S-IMCK[j], "Extended Session Key Generating Function" | 0x00 | 0x00 | 
0x00 | 0x40)

This may change the existing implementation but will make it more clear - need 
to create and call just one KDF function.

We can remove 0x00 that comes after the key label - while it is required by RFC 
5295. But there the key label is also ASCII printable string. Joe, do you 
remember what was the motivation to put 0x00 after the key label parameter?

Oleg

On Thu, Oct 22, 2020 at 2:54 AM Joseph Salowey 
mailto:j...@salowey.net>> wrote:
(I accidentally dropped this list from the conversation)

On Wed, Oct 21, 2020 at 4:48 PM Jorge Vergara 
mailto:jover...@microsoft.com>> 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:
>
>IMCK[j] = TLS-PRF(S-IMCK[j-1], "Inner Methods Compound Keys", IMSK[j]) = 
>P_(S-IMCK[j-1], "Inner Methods Compound Keys" | IMSK[j])

Yes, this is what I implemented. As you mentioned, there are multiple possible 
interpretations of this since the TEAP usage is incorrect. However, my 
implementation does interop with at least 2 large vendor implementations. If 
the implementations were using different calculations here, the Wi-Fi/Ethernet 
connections that depend on the MSK would fail. But since connections work, I 
can assume we are all using the same implementation and arriving at the same 
MSK. Cisco is one of the implementations that I have tested against which is 
why I was hoping Oleg may offer more context as to what he has seen.

[Joe] I can hope Jouni can chime in on this as well.  I think the original 
intent was to not include the length as is your suggestion.

>[Joe] Does the revision in 5167 match you implementation ( I don't think 
>Jouni's comment changes the underly calculation, just its representation)?

I have not implemented this portion of the RFC as I found it too unclear to 
work with. Thus I can’t comment on what implementations may be doing. However, 
I agree with the current revision in 5167 as the most natural interpretation. 
If others have implemented this portion of the RFC then certainly their 
comments would be welcome.

By the way, we’ve dropped the EMU group on our replies here – not sure if 
intentional or not.

Jorge Vergara

From: Joseph Salowey mailto:j...@salowey.net>>
Sent: Wednesday, October 21, 2020 4:36 PM
To: Jorge Vergara mailto:jover...@microsoft.com>>
Subject: Re: Proposed resolution for TEAP errata for 5128

On Wed, Oct 21, 2020 at 3:20 PM Jorge Vergara 
mailto:jover...@microsoft.com>> wrote:
In theory I agree this is a possible resolution. However, this doesn’t match 
any of the current TEAP

Re: [Emu] Proposed resolution for TEAP errata for 5128

2020-10-22 Thread Oleg Pekar

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. For
me it sounds better than if we align just part of KDF calls with RFC 5295
(where the output length is included into seed). Also: in some KDF calls we
do have optional data and in some no. This could be also unified.

So I would suggest introducing:
TEAP-PRF (secret, key label, optional data, length) = TLS-PRF(secret, key
label | 0x00 | optional data, length)
where a single byte 0x00 is used for no optional data, length is a 2-octet
unsigned integer in network byte order.

Then:
IMSK = First 32 octets of TEAP-PRF(EMSK, "teapbind...@ietf.org", 64) =
TLS-PRF(EMSK, "teapbind...@ietf.org" | 0x00 | 0x00 | 0x00 | 0x40)
IMCK[j] = TEAP-PRF(S-IMCK[j-1], "Inner Methods Compound Keys", IMSK[j], 60)
= TLS-PRF(S-IMCK[j-1], "Inner Methods Compound Keys" | 0x00 | IMSK[j] |
0x00 | 0x3C)
MSK = TEAP-PRF(S-IMCK[j], "Session Key Generating Function”, 64) =
TLS-PRF(S-IMCK[j], "Session Key Generating Function" | 0x00 | 0x00 | 0x00 |
0x40)
EMSK = TEAP-PRF(S-IMCK[j], ”Extended Session Key Generating Function”, 64)
= TLS-PRF(S-IMCK[j], "Extended Session Key Generating Function" | 0x00 |
0x00 | 0x00 | 0x40)

This may change the existing implementation but will make it more clear -
need to create and call just one KDF function.

We can remove 0x00 that comes after the key label - while it is required
by RFC 5295. But there the key label is also ASCII printable string. Joe,
do you remember what was the motivation to put 0x00 after the key label
parameter?

Oleg


On Thu, Oct 22, 2020 at 2:54 AM Joseph Salowey  wrote:

> (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:
>>
>> >
>>
>> >IMCK[j] = TLS-PRF(S-IMCK[j-1], "Inner Methods Compound Keys", IMSK[j])
>> = P_(S-IMCK[j-1], "Inner Methods Compound Keys" | IMSK[j])
>>
>>
>>
>> Yes, this is what I implemented. As you mentioned, there are multiple
>> possible interpretations of this since the TEAP usage is incorrect.
>> However, my implementation does interop with at least 2 large vendor
>> implementations. If the implementations were using different calculations
>> here, the Wi-Fi/Ethernet connections that depend on the MSK would fail. But
>> since connections work, I can assume we are all using the same
>> implementation and arriving at the same MSK. Cisco is one of the
>> implementations that I have tested against which is why I was hoping Oleg
>> may offer more context as to what he has seen.
>>
>>
>>
> [Joe] I can hope Jouni can chime in on this as well.  I think the original
> intent was to not include the length as is your suggestion.
>
>
>
>> >[Joe] Does the revision in 5167 match you implementation ( I don't
>> think Jouni's comment changes the underly calculation, just its
>> representation)?
>>
>>
>>
>> I have not implemented this portion of the RFC as I found it too unclear
>> to work with. Thus I can’t comment on what implementations may be doing.
>> However, I agree with the current revision in 5167 as the most natural
>> interpretation. If others have implemented this portion of the RFC then
>> certainly their comments would be welcome.
>>
>>
>> By the way, we’ve dropped the EMU group on our replies here – not sure if
>> intentional or not.
>>
>>
>>
>> Jorge Vergara
>>
>>
>>
>> *From:* Joseph Salowey 
>> *Sent:* Wednesday, October 21, 2020 4:36 PM
>> *To:* Jorge Vergara 
>> *Subject:* Re: Proposed resolution for TEAP errata for 5128
>>
>>
>>
>>
>>
>>
>>
>> On Wed, Oct 21, 2020 at 3:20 PM Jorge Vergara 
>> wrote:
>>
>> 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 a seed. In terms of P_, this means
>> implementations are performing the calculation without a seed.
>>
>>
>>
>> RFC 5246 defines the TLS 1.2 PRF as:
>>
>> PRF(secret, label, seed) = P_(secret, label + seed)
>>
>>
>>
>> So the calculation implementations are currently performing with an empty
>> seed ends up as:
>>
>> P_(secret, label)
>>
>>
>>
>> Note that in RFC 5295, the length *is* explicitly mentioned as being
>> concatenated with the label
>>
>> USRK = KDF(EMSK, key label | "\0" | optional data | length)
>>
>>
>>
>> RFC 5295 is mentioned earlier in the TEAP RFC, in the section covered by
>> errata 5127. *However* it is not mentioned in this portion of the RFC.
>> Since this calculation is not on an

Re: [Emu] Proposed resolution for TEAP errata for 5128

2020-10-21 Thread Joseph Salowey

(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:
>
> >
>
> >IMCK[j] = TLS-PRF(S-IMCK[j-1], "Inner Methods Compound Keys", IMSK[j]) =
> P_(S-IMCK[j-1], "Inner Methods Compound Keys" | IMSK[j])
>
>
>
> Yes, this is what I implemented. As you mentioned, there are multiple
> possible interpretations of this since the TEAP usage is incorrect.
> However, my implementation does interop with at least 2 large vendor
> implementations. If the implementations were using different calculations
> here, the Wi-Fi/Ethernet connections that depend on the MSK would fail. But
> since connections work, I can assume we are all using the same
> implementation and arriving at the same MSK. Cisco is one of the
> implementations that I have tested against which is why I was hoping Oleg
> may offer more context as to what he has seen.
>
>
>
[Joe] I can hope Jouni can chime in on this as well.  I think the original
intent was to not include the length as is your suggestion.



> >[Joe] Does the revision in 5167 match you implementation ( I don't think
> Jouni's comment changes the underly calculation, just its representation)?
>
>
>
> I have not implemented this portion of the RFC as I found it too unclear
> to work with. Thus I can’t comment on what implementations may be doing.
> However, I agree with the current revision in 5167 as the most natural
> interpretation. If others have implemented this portion of the RFC then
> certainly their comments would be welcome.
>
>
> By the way, we’ve dropped the EMU group on our replies here – not sure if
> intentional or not.
>
>
>
> Jorge Vergara
>
>
>
> *From:* Joseph Salowey 
> *Sent:* Wednesday, October 21, 2020 4:36 PM
> *To:* Jorge Vergara 
> *Subject:* Re: Proposed resolution for TEAP errata for 5128
>
>
>
>
>
>
>
> On Wed, Oct 21, 2020 at 3:20 PM Jorge Vergara 
> wrote:
>
> 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 a seed. In terms of P_, this means
> implementations are performing the calculation without a seed.
>
>
>
> RFC 5246 defines the TLS 1.2 PRF as:
>
> PRF(secret, label, seed) = P_(secret, label + seed)
>
>
>
> So the calculation implementations are currently performing with an empty
> seed ends up as:
>
> P_(secret, label)
>
>
>
> Note that in RFC 5295, the length *is* explicitly mentioned as being
> concatenated with the label
>
> USRK = KDF(EMSK, key label | "\0" | optional data | length)
>
>
>
> RFC 5295 is mentioned earlier in the TEAP RFC, in the section covered by
> errata 5127. *However* it is not mentioned in this portion of the RFC.
> Since this calculation is not on an EMSK, I do not believe RFC 2395 applies
> and this is likely why implementations went with the seedless
> P_(secret, label) calculation instead.
>
>
>
> Is there concern about updating the RFC in a way that breaks existing
> implementations?
>
>
>
> [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:
>
>
>
> IMCK[j] = TLS-PRF(S-IMCK[j-1], "Inner Methods Compound Keys", IMSK[j]) =
> P_(S-IMCK[j-1], "Inner Methods Compound Keys" | IMSK[j])
>
>
>
> taken out to 60 bytes.  The problem is that the TEAP spec references a
> TLS-PRF in a way that it does not define.  I think the errata points out
> the definition that should be used:
>
>
>
> PRF(secret, label, seed) = P_(secret, label + seed)
>
>
>
> That does not include length so the 60 in the original definition is
> ambiguous.   The new text would then be something like:
>
>
>
> IMCK[j] = TLS-PRF(S-IMCK[j-1], "Inner Methods Compound Keys", IMSK[j])
> to generate a length of 60 bytes
>
>
>
> Does the revision in 5167 match you implementation ( I don't think
> Jouni's comment changes the underly calculation, just its representation)?
>
>
>
>
>
>
>
>
>
>
>
> Jorge Vergara
>
>
>
> *From:* Joseph Salowey 
> *Sent:* Wednesday, October 21, 2020 2:34 PM
> *To:* EMU WG ; Jouni Malinen ; Jorge Vergara <
> jover...@microsoft.com>; Oleg Pekar (olpekar) 
> *Subject:* Proposed resolution for TEAP errata for 5128
>
>
>
> Errata 5128: https://www.rfc-editor.org/errata/eid5128
>

Re: [Emu] Proposed resolution for TEAP errata for 5128

2020-10-21 Thread Jorge Vergara

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 a seed. In terms of P_, this means implementations 
are performing the calculation without a seed.

RFC 5246 defines the TLS 1.2 PRF as:
PRF(secret, label, seed) = P_(secret, label + seed)

So the calculation implementations are currently performing with an empty seed 
ends up as:
P_(secret, label)

Note that in RFC 5295, the length *is* explicitly mentioned as being 
concatenated with the label
USRK = KDF(EMSK, key label | "\0" | optional data | length)

RFC 5295 is mentioned earlier in the TEAP RFC, in the section covered by errata 
5127. *However* it is not mentioned in this portion of the RFC. Since this 
calculation is not on an EMSK, I do not believe RFC 2395 applies and this is 
likely why implementations went with the seedless P_(secret, label) 
calculation instead.

Is there concern about updating the RFC in a way that breaks existing 
implementations?

Jorge Vergara

From: Joseph Salowey 
Sent: Wednesday, October 21, 2020 2:34 PM
To: EMU WG ; Jouni Malinen ; Jorge Vergara 
; Oleg Pekar (olpekar) 
Subject: Proposed resolution for TEAP errata for 5128

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)

Note:
According to

RFC5246 The Transport Layer Security (TLS) Protocol Version 1.2

5. HMAC and the Pseudorandom Function

"TLS's PRF is created by applying P_hash to the secret as:

PRF(secret, label, seed) = P_(secret, label + seed)"

In terms of P_ this would look like the following with the length 
represented as a 2 byte value in network byte order:

IMCK[j] = P_(S-IMCK[j-1], "Inner Methods Compound Keys" | IMSK[j] | 0x00 
| 0x3C)


___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

[Emu] Proposed resolution for TEAP errata for 5128

2020-10-21 Thread Joseph Salowey

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)

Note:
According to

RFC5246 The Transport Layer Security (TLS) Protocol Version 1.2

5. HMAC and the Pseudorandom Function

"TLS's PRF is created by applying P_hash to the secret as:

PRF(secret, label, seed) = P_(secret, label + seed)"

In terms of P_ this would look like the following with the length
represented as a 2 byte value in network byte order:

IMCK[j] = P_(S-IMCK[j-1], "Inner Methods Compound Keys" | IMSK[j] |
0x00 | 0x3C)
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] Proposed resolution for TEAP errata for 5128

Re: [Emu] Proposed resolution for TEAP errata for 5128

Re: [Emu] Proposed resolution for TEAP errata for 5128

Re: [Emu] Proposed resolution for TEAP errata for 5128

Re: [Emu] Proposed resolution for TEAP errata for 5128

Re: [Emu] Proposed resolution for TEAP errata for 5128

Re: [Emu] Proposed resolution for TEAP errata for 5128

Re: [Emu] Proposed resolution for TEAP errata for 5128

Re: [Emu] Proposed resolution for TEAP errata for 5128

Re: [Emu] Proposed resolution for TEAP errata for 5128

Re: [Emu] Proposed resolution for TEAP errata for 5128

Re: [Emu] Proposed resolution for TEAP errata for 5128

[Emu] Proposed resolution for TEAP errata for 5128

13 matches

Site Navigation

Mail list logo

Footer information