Subject: [Emu] RFC 7170 (TEAP) errata

From: Jouni Malinen <[email-masked]>
Date: Mon, 1 Jul 2019 23:10:59 +0300

I've filed number of errata entries against RFC 7170. The email responses
from rfc-editor seem to be cc'ed to this mailing list, but I don't receive
them from the list or see them in the list archive. Anyway, if there are
anyone here who would be interested in getting these reports reviewed and
the issues addressed, that would be most helpful.

Some of these items are significant technical issues that prevent me from
implemented the protocol and would also make me question how any
implementation of TEAP would actually be able to comply with the RFC I can
figure out the most likely answers to some of the entries, but there is no
straightforward way of resolving the issues related to

(1) Crypto-Binding TLV format for the cases where the negotiated TLS cipher
suite uses SHA256 (or SHA384, for that matter) instead of SHA-1 (and I'd
hope all deployments of TEAP would be recent enough to avoid use of
SHA-1..):
https://www.rfc-editor.org/errata/eid5768

(2) S-IMCK[j] derivation when inner EAP methods in the sequence derive both
MSK and EMSK (or even more complicated, if there are multiple inner EAP
authentication methods that have difference in whether they derive MSK or
EMSK):
https://www.rfc-editor.org/errata/eid5770

I'd hope to avoid having to guess or make my own specification of how this
is supposed to work before being able to implement this (and then have to
re-implement everything if others disagree with that interpretation/guess
on the design), so any feedback on these items would be very welcome so
that there would be a general agreement on how the protocol is supposed to
work to provide better chances for getting interoperable implementations.

- Jouni

---

From: Joseph Salowey <[email-masked]>
Date: Mon, 22 Jul 2019 13:50:26 -0400

On Mon, Jul 1, 2019 at 4:11 PM Jouni Malinen <[email-masked]> wrote:

> <snip>
>
> (1) Crypto-Binding TLV format for the cases where the negotiated TLS
> cipher suite uses SHA256 (or SHA384, for that matter) instead of SHA-1 (and
> I'd hope all deployments of TEAP would be recent enough to avoid use of
> SHA-1..):
> [Joe] I'd like to hear if anyone has an implementation, and how they
implemented on a cipher suite that is not SHA-1.  My feeling is that it
would be better to make the TLV length variable with the hash length.
However, I do not see why truncating would work as well.

>
> - Jouni
>
> _______________________________________________
> Emu mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/emu
>

---

From: Joseph Salowey <[email-masked]>
Date: Mon, 22 Jul 2019 15:12:15 -0400

On Mon, Jul 1, 2019 at 4:11 PM Jouni Malinen <[email-masked]> wrote:

> <snip>
>
> (2) S-IMCK[j] derivation when inner EAP methods in the sequence derive
> both MSK and EMSK (or even more complicated, if there are multiple inner
> EAP authentication methods that have difference in whether they derive MSK
> or EMSK):
[Joe]  I'd like to hear from implementers on this one.

I think the intent is that section 5.4 should say the S-IMCK is generated
as specified  as described in section 5.2.

Section 5.2 does provide a mechanism to derive the S-IMCK at the end of the
section.  Each IMCK can be derived in one of 3 ways:
- MSK
- EMSK
- 0s if the method is not key generating

There is ambiguity on how to derive each IMSK in the case that both sides
do not have the same capability to export the EMSK.   I think the steps
involving the compound MAC are meant to disambiguate this situation.

Is the problem that the section does not explicitly say how to use the
compound MAC sent to determine which IMCK derivation to use?

---

From: Alan DeKok <[email-masked]>
Date: Mon, 22 Jul 2019 15:47:02 -0400

On Jul 22, 2019, at 1:50 PM, Joseph Salowey <[email-masked]> wrote:
> [Joe] I'd like to hear if anyone has an implementation, and how they implemented on a cipher suite that is not SHA-1.

  TBH, I haven't seen an implementation.

  I suspect that the lack of implementations is why these questions are only coming up now.

>  My feeling is that it would be better to make the TLV length variable with the hash length.  However, I do not see why truncating would work as well. 

  My $0.02 is to allow a variable TLV length.

  I think it's OK to leave these as errata now.  I'm not sure that any existing EMU document would be appropriate for these changes.

  Alan DeKok.

---

From: Jouni Malinen <[email-masked]>
Date: Tue, 23 Jul 2019 11:46:21 +0300

> However, I do not see why truncating would work as well.

For now, I ended up implementing this with truncation to 20 octets since
it was a bit simpler to do. I have an implementation with support for
SHA-1, SHA-256, and SHA-384; and not allowing MD5 at all to avoid
questions about shorter than 20 octets and use of obsolete algorithms.
That said, I think it would be better to make the Compound MAC fields to
be of variable length (i.e., be based on the output length of the
negotiated MAC algorithm) so that the full MAC value can be exchanged.
This would mean the Crypto-Binding TLV length would need to be marked
variable.

I'm ready to change my implementation to do this as soon as there is
some clear indication on that being the direction TEAP should go to.
This is a straightforward change in the implementation, but I don't want
to be moving back and forth on this before seeing some signs of
consensus on the TEAP specification side.

-- 
Jouni Malinen                                            PGP id EFC895FA

---

From: Jouni Malinen <[email-masked]>
Date: Tue, 23 Jul 2019 12:01:31 +0300

> [Joe]  I'd like to hear from implementers on this one.

My current implementation derives two copies of S-IMCK[i] values (one
based on MSK and the other one based on EMSK from the inner EAP method).
Both of these are initialized to session_key_seed. If the inner EAP
method derives EMSK, EMSK Compound MAC gets included in crypto-binding.
MSK is assumed to be derived for all cases where EMSK is derived. If
neither MSK nor EMSK is derived, the "MSK" S-IMCK[j] is derived based on
the all-zeros-IMSK and that is then used to calculate the MSK Compound
MAC field. This implementation does not support a sequence of more than
one inner EAP authentication method that derives keys, so the more
complicated mixes do not show up. Or well, in theory, there is support
for EAP-TNC, so that could show these cases (e.g., with EAP-MSCHAPv2
deriving MSK and that followed by EAP-TNC not deriving any keys), but I
have not tested that combination yet.

I'm currently deriving the TEAP MSK and EMSK based on the MSK-based
S-IMCK[j], but that would be trivial to change to use EMSK-based
S-IMCK[j] (if available) for TEAP EMSK derivation. However, this part
would need to be done based on whether both ends actually claimed to
derive EMSK from the inner EAP method(s) (and with even more complex
rules if only a subset of the inner EAP methods derive EMSK while
another subset does not and those subsets are different at each end).

> - 0s if the method is not key generating

Well, yes, but this is not very helpful now that TEAP added two Compound
MAC values into crypto-binding. There is clearly an assumption that
different IMSK[j] values (and from that, two different S-IMSK[j] values)
are derived if the inner EAP method derives both an MSK and EMSK, but
the sections describing derivations and use of these keys do not take
into account that need for two independent values.

> involving the compound MAC are meant to disambiguate this situation.

They were probably meant to do that, but they did not really.

> compound MAC sent to determine which IMCK derivation to use?

No, the problem is in one of the design (crypto-binding
construction/validation) assuming there are two values (MSK-based and
EMSK-based) while the IMSK[j]/IMCK[j] derivation part assuming only one
value (EMSK-based, if available, otherwise MSK-based) is derived.
Furthermore, the TEAP MSK/EMSK derivation rules assumes there is only
one S-IMCK[j]. This would have all worked fine if the crypto-binding
design from EAP-FAST had not been extended to cover the EMSK case, but
I'd guess that addition was done based on some review, but that did not
end up getting fully baked into the TEAP design to make it work.

---

From: Michael Richardson <[email-masked]>
Date: Tue, 23 Jul 2019 11:10:04 -0400

>> My feeling is that it would be better to make the TLV length variable
    >> with the hash length.  However, I do not see why truncating would work
    >> as well.

    >   I think it's OK to leave these as errata now.  I'm not sure that any
    > existing EMU document would be appropriate for these changes.

Apparently there will soon be a mechanism deployed which will let people
see the documents with the errata *applied* on the rfc-editor.org site, so
it's a good idea to formally accept the errata, make a decision and then you
can generate a diff.

It seems like having the TLV length be variable is the right answer.
(I don't have a TEAP implementation.... yet)

-- 
]               Never tell me the odds!                 | ipv6 mesh networks [ 
]   Michael Richardson, Sandelman Software Works        | network architect  [ 
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [