A typo: "Crypto-Binding TLS" ==> "Crypto-Binding TLV"
On Sun, Nov 1, 2020 at 11:42 PM Joseph Salowey <j...@salowey.net> wrote: > The section 5 revision is rewritten to reflect handling of the case where > no MSK is generated and text on handling the 0 MSK is moved from errata > 5770. this erratum could use more review. Please comment on the list or > in the PR. > > Section 4 PR - https://github.com/emu-wg/teap-errata/pull/12 > Section 5 PR - https://github.com/emu-wg/teap-errata/pull/11 > > > Errata ID: 5775 - https://www.rfc-editor.org/errata/eid5775 > Status: verified > Type: Technical > Revision: > > Section 4.2.13 Says: > > The Crypto-Binding TLV MUST be exchanged and verified before the > final Result TLV exchange, regardless of whether there is an inner > EAP method authentication or not. It MUST be included with the > Intermediate-Result TLV to perform cryptographic binding after each > successful EAP method in a sequence of EAP methods, before proceeding > with another inner EAP method. The Crypto-Binding TLV is valid only > if the following checks pass: > > It should say: > > The Crypto-Binding TLV MUST be exchanged and verified before the > final Result TLV exchange, regardless of whether there is an inner > EAP method authentication or not. It MUST be included with each > successful Intermediate-Result TLV to perform cryptographic binding > after each EAP authentication or basic password method, before > proceeding with another authentication exchange. If no MSK or EMSK > has been generated and a Crypto-Binding TLS is required then the MSK > Compound MAC field contains the MAC using keys generated according > to section 5.2. The Crypto-Binding TLV is valid only if the following > checks pass: > > Section 5.2 says: > > The first step in these calculations is the generation of the base > compound key, IMCK[n] from the session_key_seed, and any session keys > derived from the successful execution of nth inner EAP methods. The > inner EAP method(s) may provide Inner Method Session Keys (IMSKs), > IMSK1..IMSKn, corresponding to inner method 1 through n. > > It should say: > > The first step in these calculations is the generation of the base > compound key, IMCK[j] from the session_key_seed, and any session keys > derived from the successful execution of jth inner EAP authentication > methods or basic password authentication. The inner EAP method(s) may > provide Inner Method Session Keys (IMSKs), IMSK1..IMSKn, corresponding > to inner method 1 through n. When the jth exchange, such as a basic > password exchange, does not derive key material then a special 0 IMSK > is used as described below. > > Section 5.2 says: > > If the ith inner method does not generate an EMSK or MSK, then IMSKi > is set to zero (e.g., MSKi = 32 octets of 0x00s). If an inner method > fails, then it is not included in this calculation. > > It Should say: > > If no inner EAP authentication method is run then no EMSK or MSK > will be generated (e.g. when basic password authentication > is used or when no inner method has been run and the crypto-binding TLV > for the Result-TLV needs to be generated). In this case, IMSK[j] > is set to zero (i.e., MSK = 32 octets of 0x00s). If an inner method > fails, then it is not included in this calculation. > > Section 5.4 Says > > TEAP authentication assures the Master Session Key (MSK) and Extended > Master Session Key (EMSK) output from the EAP method are the result > of all authentication conversations by generating an Intermediate > Compound Key (IMCK). The IMCK is mutually derived by the peer and > the server as described in Section 5.2 by combining the MSKs from inner > EAP methods with key material from TEAP Phase 1. The resulting > MSK and EMSK are generated as part of the IMCKn key hierarchy as > follows: > > It should say: > > TEAP authentication assures the Master Session Key (MSK) and Extended > Master Session Key (EMSK) output from the EAP method are the result > of all authentication conversations by generating an Intermediate > Compound Key (IMCK). The IMCK is mutually derived by the peer and > the server as described in Section 5.2 by combining the IMSKs from inner > EAP authentication and basic password methods with key material from > TEAP Phase 1. The resulting MSK and EMSK are generated as part of the > IMCK key hierarchy as follows: > > Notes: > > This revision clarifies handling cases when the 0 MSK is used because no > key material is derived. > >
_______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
