Re: [Emu] Proposed resolution for TEAP errata 5775
On Mon, Oct 26, 2020 at 1:25 AM Oleg Pekar wrote: > It Should say: >> >> S-IMCK[j] = first 40 octets of IMCK[j] >> CMK[j] = last 20 octets of IMCK[j] >> where TLS-PRF is the PRF negotiated as part of TLS handshake [RFC5246]. >> If no inner EAP method has been run the S-IMCK and CMK are generated as >> above from S-IMCK[0]. > > > Joe, for me it still doesn't sound as exact enough instructions. We should > explain how to generate S-IMCK and CMK for no inner method case with more > details. > > [Joe] Good catch, S-IMCK[0] is only 40 octets. Looking at this I think it makes more sense to Change 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). To: If the jth inner method does not generate an EMSK or MSK, or no inner method has been run then IMSK[j] is set to zero (32 octets of 0x00s). > 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. > > This still remains an open question whether we MUST send Crypto-Binding > TLV after Basic-Password-Authentication exchange or not. Is > Basic-Password-Authentication treated just as a case of no inner EAP > authentication method? It is also discussed in the errata 5844 thread. > > [Joe] I don't think so, but let's discuss on the 5844 thread. > Regarding introduction of Zero-MSK flag in Crypto-Binding TLV - do you > think it is unnecessary? So if one peer doesn't export a specific inner > method MSK and ESMK and uses Zero-MSK and another peer expects MSK or ESMK > - then the Crypto-Binding TLV exchange will fail naturally. Maybe it's > worth saying exactly that if the inner method exports MSK or EMSK then each > peer MUST use it and not Zero-MSK. > [Joe] It doesn't seem to me that the Zero-MSK flag is necessary, I'd rather not add new signals if we do not need them now. If a method generates an MSK then I think it must be used. We can add a sentence saying that to the above revision. If the jth inner method does not generate an EMSK or MSK, or no inner method has been run then IMSK[j] is set to zero (32 octets of 0x00s). If a method generates an MSK or EMSK the zero IMSK MUST NOT be used. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Proposed resolution for TEAP errata 5775
> > It Should say: > > S-IMCK[j] = first 40 octets of IMCK[j] > CMK[j] = last 20 octets of IMCK[j] > where TLS-PRF is the PRF negotiated as part of TLS handshake [RFC5246]. > If no inner EAP method has been run the S-IMCK and CMK are generated as > above from S-IMCK[0]. Joe, for me it still doesn't sound as exact enough instructions. We should explain how to generate S-IMCK and CMK for no inner method case with more details. 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. This still remains an open question whether we MUST send Crypto-Binding TLV after Basic-Password-Authentication exchange or not. Is Basic-Password-Authentication treated just as a case of no inner EAP authentication method? It is also discussed in the errata 5844 thread. Regarding introduction of Zero-MSK flag in Crypto-Binding TLV - do you think it is unnecessary? So if one peer doesn't export a specific inner method MSK and ESMK and uses Zero-MSK and another peer expects MSK or ESMK - then the Crypto-Binding TLV exchange will fail naturally. Maybe it's worth saying exactly that if the inner method exports MSK or EMSK then each peer MUST use it and not Zero-MSK. > ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
[Emu] Proposed resolution for TEAP errata 5775
Errata 5775: https://www.rfc-editor.org/errata/eid5775 Proposed Status: Verified Revision: Section 5.2 Says: S-IMCK[j] = first 40 octets of IMCK[j] CMK[j] = last 20 octets of IMCK[j] where TLS-PRF is the PRF negotiated as part of TLS handshake [RFC5246]. It Should say: S-IMCK[j] = first 40 octets of IMCK[j] CMK[j] = last 20 octets of IMCK[j] where TLS-PRF is the PRF negotiated as part of TLS handshake [RFC5246]. If no inner EAP method has been run the S-IMCK and CMK are generated as above from S-IMCK[0]. 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. If an inner EAP method is not executed with successful authentication then the EMSK Compound MAC field contains the MAC using keys generated according to section 5.2. 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: Notes: How to calculate the CMK and other keys when no inner method was run was unspecified. This revision specifies that the CMK is generated from S-IMSK[0] and the MAC goes into the EMSK field. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
