Re: [Emu] TEAP errata 5770

[Oleg Pekar]

Joe, nice proposal. Few questions:
1. We have a case of Basic Password Authentication instead of inner method
thus we should also use Crypto-Binding TLV based on Zero-MSK after it
2. As Eliot mentioned, we have a case of no inner method at all - we should
use Crypto-Binding TLV based on Zero-MSK after it
3. Since it is not clear whether MSK or Zero-MSK is used - we should
introduce a new flag value for Crypto-Binding TLV: "0" - Zero-MSK
based Compound MAC is used in place of MSK Compound MAC field.
4. We have a TLS-PRF usage ambiguity here (Errata 5127 and 5128):
TLS 1.2 RFC 5246 in section "5.  HMAC and the Pseudorandom Function"
defines PRF(secret, label, seed) = P_(secret, label + seed)

TEAP RFC uses TLS-PRF several times:
* IMSK = First 32 octets of TLS-PRF(EMSK, "teapbind...@ietf.org" | "\0" |
64)
  The call refers to RFC 5295 that defines USRK = KDF(EMSK, key label |
"\0" | optional data | length) but that RFC says "USRKs MUST be at least 64
octets in length" and IMSK is 32 octets
* IMCK[j] = TLS-PRF(S-IMCK[j-1], "Inner Methods Compound Keys", IMSK[j], 60)
* MSK  = TLS-PRF(S-IMCK[j], "Session Key Generating Function", 64) and
similar for EMSK

We can see that all three times the parameters are different and don't
exactly fit the definition and this creates some confusion.

In the other earlier thread you mentioned that truncation of 64-octets USRK
to 32 octet is valid. In yet another thread you mentioned that we should
define TLS-PRF function with the output size as a parameter and we should
just concatenate for all TLS-PRF calls all the parameters starting from the
second. Is that understanding correct? This should be also helpful when
mapping to TLS1.3 HKDF extract and expand functions.

Thanks
Oleg

On Thu, Oct 10, 2019 at 11:00 AM Eliot Lear  wrote:

> Just one comment:
>
> TEAP does not *require* an inner method, and indeed for IoT it is not
> necessary.
>
> Eliot
>
> On 9 Oct 2019, at 07:46, Joseph Salowey  wrote:
>
> Based on Jouni's analysis the derivation of the S-IMCKs is not well
> specified.  To me it looks like the solution to handle an arbitrary number
> of methods that may or may not make an EMSK available would be fairly
> complex.
>
> I think the most straight forward solution is to either always assume that
> for an EMSK generating method the EMSK is either always available or always
> unavailable.  It seems that it is safer to always assume that the EMSK is
> unavailable and will therefore never be used.  I think this has the
> following implications:
>
> -  The S-IMCK is always generated from the inner method MSK or the
> all-zero value if the method does not generate key material.
> -  The EMSK compound MAC is not used
> -  Implementations must have a policy that accepts MSK MACs
>
> It would appear that from a cryptographic analysis point of view the MSK
> and EMSK are equivalent since these keys will only be used in these
> TEAP calculations and not for other purposes..  There are documented
> drawbacks of using the MSK described in RFC7029 (
> https://tools.ietf.org/html/rfc7029#page-12).   If the properties of the
> EMSK binding are needed in the use cases currently under consideration then
> I think we could redefine the way the EMSK MAC to be computed from the EMSK
> of the inner method changing the above to
>
> -  The S-IMCK is always generated from the inner method MSK or the
> all-zero value if the method does not generate key material.
> - Compute EMSK MAC from the inner-method EMSK instead of the S-IMCK
>  Compound-MAC = MAC( EMSK[J], BUFFER )
> -  Implementations have a policy that prevents EMSK downgrade to MSK
>
> Hopefully there is a more elegant solution. Any ideas?
>
> Joe
> ___
> Emu mailing list
> Emu@ietf.org
> https://www.ietf.org/mailman/listinfo/emu
>
>
> ___
> Emu mailing list
> Emu@ietf.org
> https://www.ietf.org/mailman/listinfo/emu
>
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] TEAP errata 5770

[Eliot Lear]

Just one comment:

TEAP does not require an inner method, and indeed for IoT it is not necessary.

Eliot

> On 9 Oct 2019, at 07:46, Joseph Salowey  wrote:
> 
> Based on Jouni's analysis the derivation of the S-IMCKs is not well 
> specified.  To me it looks like the solution to handle an arbitrary number of 
> methods that may or may not make an EMSK available would be fairly complex.
> 
> I think the most straight forward solution is to either always assume that 
> for an EMSK generating method the EMSK is either always available or always 
> unavailable.  It seems that it is safer to always assume that the EMSK is 
> unavailable and will therefore never be used.  I think this has the following 
> implications:
> 
> -  The S-IMCK is always generated from the inner method MSK or the all-zero 
> value if the method does not generate key material.
> -  The EMSK compound MAC is not used
> -  Implementations must have a policy that accepts MSK MACs
> 
> It would appear that from a cryptographic analysis point of view the MSK and 
> EMSK are equivalent since these keys will only be used in these TEAP 
> calculations and not for other purposes..  There are documented drawbacks of 
> using the MSK described in RFC7029 
> (https://tools.ietf.org/html/rfc7029#page-12 
> ).   If the properties of the 
> EMSK binding are needed in the use cases currently under consideration then I 
> think we could redefine the way the EMSK MAC to be computed from the EMSK of 
> the inner method changing the above to
> 
> -  The S-IMCK is always generated from the inner method MSK or the all-zero 
> value if the method does not generate key material.
> - Compute EMSK MAC from the inner-method EMSK instead of the S-IMCK
>  Compound-MAC = MAC( EMSK[J], BUFFER )
> -  Implementations have a policy that prevents EMSK downgrade to MSK
> 
> Hopefully there is a more elegant solution. Any ideas?
> 
> Joe
> ___
> Emu mailing list
> Emu@ietf.org
> https://www.ietf.org/mailman/listinfo/emu



signature.asc
Description: Message signed with OpenPGP
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] TEAP errata 5770

[Joseph Salowey]

On Tue, Oct 8, 2019 at 10:46 PM Joseph Salowey  wrote:

> Based on Jouni's analysis the derivation of the S-IMCKs is not well
> specified.  To me it looks like the solution to handle an arbitrary number
> of methods that may or may not make an EMSK available would be fairly
> complex.
>
> I think the most straight forward solution is to either always assume that
> for an EMSK generating method the EMSK is either always available or always
> unavailable.  It seems that it is safer to always assume that the EMSK is
> unavailable and will therefore never be used.  I think this has the
> following implications:
>
> -  The S-IMCK is always generated from the inner method MSK or the
> all-zero value if the method does not generate key material.
> -  The EMSK compound MAC is not used
> -  Implementations must have a policy that accepts MSK MACs
>
> It would appear that from a cryptographic analysis point of view the MSK
> and EMSK are equivalent since these keys will only be used in these
> TEAP calculations and not for other purposes.  There are documented
> drawbacks of using the MSK described in RFC7029 (
> https://tools.ietf.org/html/rfc7029#page-12).   If the properties of the
> EMSK binding are needed in the use cases currently under consideration then
> I think we could redefine the way the EMSK MAC to be computed from the EMSK
> of the inner method changing the above to
>
> -  The S-IMCK is always generated from the inner method MSK or the
> all-zero value if the method does not generate key material.
> - Compute EMSK MAC from the inner-method EMSK instead of the S-IMCK
>  Compound-MAC = MAC( EMSK[J], BUFFER )
> -  Implementations have a policy that prevents EMSK downgrade to MSK
>
> Hopefully there is a more elegant solution. Any ideas?
>
>
[Joe] It might be better to do the following:

Singe S-IMCK chain, but when an EMSK method is used there are two pre
S-IMCK keys generated, one for the EMSK and one for the MSK.  These are
used to calculate two CMKs for Compound MACs for EMSK and MSK
respectively.  If the server responds with an EMSK MAC then the pre S-IMCK
generated from the EMSK is used as the S-IMCK for future calculations if
not then the one from the MSK is used.

Modification to section 5.2 Intermediate Compound Key Derivations:

When an EMSK generating method is used, then two compound MAC keys are
generated, one based on the IMSK with the EMSK from the current method and
on from the MSK from the current method as follows:

 S-IMCK[j-1] = compound session key from previous method:

 IMSK-EMSK[J] = First 32 octets of TLS-PRF(EMSK,
"teapbind...@ietf.org" | "\0" | 64)

 IMSK-MSK = MSK


 IMCK-EMSK[j] = TLS-PRF(S-IMCK[j-1], "Inner Methods Compound Keys",
IMSK-EMSK[j], 60)
   S-IMCK-EMSK[j] = first 40 octets of IMCK-EMSK[j]
   CMK-EMSK[j] = last 20 octets of IMCK-EMSK[j]


 IMCK-MSK[j] = TLS-PRF(S-IMCK[j-1], "Inner Methods Compound Keys",
IMSK-MSK[j], 60)
   S-IMCK-MSK[j] = first 40 octets of IMCK-EMSK[j]
   CMK-MSK[j] = last 20 octets of IMCK-EMSK[j]


  CMK-MSK[J] is used to calculate the MSK compound MAC

  CMK-EMSK[J] is used to calculate the EMSK compound MAC

If the EMSK MAC is returned form the server then the

 S-IMCK[j] = S-IMCK-EMSK[j]

else
  S-IMCK[j] = S-IMCK-MSK[j]

Modifications to  5.3.  Computing the Compound MAC

The Compound MAC EMSK computation is as follows:

  CMK-EMSK = CMK-EMSK[j]
  Compound-MAC-EMSK = MAC( CMK-EMSK, BUFFER )


The Compound MAC MSK computation is as follows:

  CMK-MSK = CMK-MSK[j]
  Compound-MAC-MSK = MAC( CMK-MSK, BUFFER )


I think this is more in line with what was originally intended and better
than what I originally wrote in the previous message.


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

[Emu] TEAP errata 5770

[Joseph Salowey]

Based on Jouni's analysis the derivation of the S-IMCKs is not well
specified.  To me it looks like the solution to handle an arbitrary number
of methods that may or may not make an EMSK available would be fairly
complex.

I think the most straight forward solution is to either always assume that
for an EMSK generating method the EMSK is either always available or always
unavailable.  It seems that it is safer to always assume that the EMSK is
unavailable and will therefore never be used.  I think this has the
following implications:

-  The S-IMCK is always generated from the inner method MSK or the all-zero
value if the method does not generate key material.
-  The EMSK compound MAC is not used
-  Implementations must have a policy that accepts MSK MACs

It would appear that from a cryptographic analysis point of view the MSK
and EMSK are equivalent since these keys will only be used in these
TEAP calculations and not for other purposes.  There are documented
drawbacks of using the MSK described in RFC7029 (
https://tools.ietf.org/html/rfc7029#page-12).   If the properties of the
EMSK binding are needed in the use cases currently under consideration then
I think we could redefine the way the EMSK MAC to be computed from the EMSK
of the inner method changing the above to

-  The S-IMCK is always generated from the inner method MSK or the all-zero
value if the method does not generate key material.
- Compute EMSK MAC from the inner-method EMSK instead of the S-IMCK
 Compound-MAC = MAC( EMSK[J], BUFFER )
-  Implementations have a policy that prevents EMSK downgrade to MSK

Hopefully there is a more elegant solution. Any ideas?

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