On Mon, Oct 26, 2020 at 12:51 PM Jorge Vergara <jover...@microsoft.com> wrote:
> This is a detailed one so I’ve tried to go over it carefully. Most of it > looks good but I’m unsure about this part: > > > > > If an inner method fails or MAC verification > > fails then S-IMCK is not used in further calculation. > > > > It is a valid scenario that multiple authentication methods run and some > fail, but the overall TEAP authentication succeeds. For example, if two > inner EAP Authentication methods run and the first fails but the seconds > succeeds, the calculation needs to be valid. Based on the old text, that > authentication method is omitted from calculations. This is what current > implementations do. > > > > My editorial comment based on some other errata would be to that text > needs to specify “authentication” methods (per Jouni’s other errata) since > the Identity method doesn’t factor in here. I think it would also be > beneficial to be specific about the behavior of basic username and password > authentication here. Oleg made some comments to this effect on another > email. Our implementation doesn’t support basic username and password > authentication so I don’t have any prior experience here. > > [Joe] Yes I think it is fine to say EAP authentication method. I have been convinced that the spec requires crypto-binding with the basic password authentication. I'll need to add this in. > > > Jorge Vergara > > > > *From:* Joseph Salowey <j...@salowey.net> > *Sent:* Saturday, October 24, 2020 5:18 PM > *To:* EMU WG <emu@ietf.org> > *Cc:* Oleg Pekar <oleg.pekar.2...@gmail.com>; Jouni Malinen <j...@w1.fi>; > Jorge Vergara <jover...@microsoft.com> > *Subject:* Proposed Resolution to TEAP Errata 5770 > > > > Errata 5770: https://www.rfc-editor.org/errata/eid5770 > <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Ferrata%2Feid5770&data=04%7C01%7Cjovergar%40microsoft.com%7C728ceb6af6694e40e08e08d8787b669d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637391818689781723%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=RuRrXZ5c70r43Rmyl4s%2BVUKAA22nGtoenLElbCeUkmE%3D&reserved=0> > > Proposed Status: Verified > > Revision: > > > > Section 5.2 Says: > > > > On the sender of the Crypto-Binding TLV side: > > If the EMSK is not available, then the sender computes the Compound > MAC using the MSK of the inner method. > > If the EMSK is available and the sender's policy accepts MSK-based > MAC, then the sender computes two Compound MAC values. The first > is computed with the EMSK. The second one is computed using the > MSK. Both MACs are then sent to the other side. > > If the EMSK is available but the sender's policy does not allow > downgrading to MSK-generated MAC, then the sender SHOULD only send > EMSK-based MAC. > > On the receiver of the Crypto-Binding TLV side: > > If the EMSK is not available and an MSK-based Compound MAC was > sent, then the receiver validates the Compound MAC and sends back > an MSK-based Compound MAC response. > > If the EMSK is not available and no MSK-based Compound MAC was > sent, then the receiver handles like an invalid Crypto-Binding TLV > with a fatal error. > > If the EMSK is available and an EMSK-based Compound MAC was sent, > then the receiver validates it and creates a response Compound MAC > using the EMSK. > > If the EMSK is available but no EMSK-based Compound MAC was sent > and its policy accepts MSK-based MAC, then the receiver validates > it using the MSK and, if successful, generates and returns an MSK- > based Compound MAC. > > If the EMSK is available but no EMSK Compound MAC was sent and its > policy does not accept MSK-based MAC, then the receiver handles > like an invalid Crypto-Binding TLV with a fatal error. > > > > 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: > > > > On the sender of the Crypto-Binding TLV side: > > If the EMSK is not available, then the sender computes the Compound > MAC using the CMK generated from MSK (CMK-MSK) of the inner method. > > If the EMSK is available and the sender's policy accepts MSK-based > MAC, then the sender computes two Compound MAC values. The first > is computed with the CMK generated from the EMSK (CMK-EMSK). The > > second one is computed using the CMK-MSK. Both MACs are > > then sent to the other side. This also means the sender must generate > > both EMSK and MSK based S-IMCKs. > > If the EMSK is available but the sender's policy does not allow > downgrading to CMK-MSK MAC, then the sender SHOULD only send > a MAC computed from the CMK-EMSK. > > On the receiver of the Crypto-Binding TLV side: > > If the EMSK is not available and an CMK-MSK Compound MAC was > sent, then the receiver validates the Compound MAC and sends back > an CMK-MSK Compound MAC response. > > If the EMSK is not available and no CMK-MSK Compound MAC was > sent, then the receiver handles like an invalid Crypto-Binding TLV > with a fatal error. > > If the EMSK is available and a CMK-EMSK Compound MAC was sent, > then the receiver validates it and creates a response Compound MAC > using the CMK-EMSK. > > If the EMSK is available but no CMK-EMSK Compound MAC was sent > and its policy accepts CMK-MSK MAC, then the receiver validates > it using the CMK-MSK and, if successful, generates and returns an MSK- > based Compound MAC. > > If the EMSK is available but no CMK-EMSK Compound MAC was sent and its > policy does not accept CMK-MSK MAC, then the receiver handles > like an invalid Crypto-Binding TLV with a fatal error. > > > > The IMSK used is either the EMSK-based IMSK or the MSK based IMSK depending > upon the rules outlined above. 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). It > is possible > > that two S-IMCKs for a step may be generated based on the rules above. In > this > > case the S-IMCK for further calculations is chosen as follows. If the MAC > based > > on the CMK-EMSK is verified then the S-IMCK generated based on the EMSK is > > used. Else, if the MAC based on the CMK-MSK is verified then the S-IMCK > > generated based on the MSK is used. If an inner method fails or MAC > verification > > fails then S-IMCK is not used in further 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. > > > > 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 methods with key material from TEAP Phase 1. > > > > Note: > > > > This revision is to clarify how to handle the case where you need to > generate > > both MSK and EMSK keys. The original text was incomplete and ambiguous > > in some places. >
_______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
