Re: [Emu] draft-dekok-emu-tls-eap-types discussion

Joseph Salowey <joe@salowey.net> Wed, 24 June 2020 04:08 UTC

Return-Path: <joe@salowey.net>
X-Original-To: emu@ietfa.amsl.com
Delivered-To: emu@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 163973A07AB for <emu@ietfa.amsl.com>; Tue, 23 Jun 2020 21:08:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.798
X-Spam-Level:
X-Spam-Status: No, score=-1.798 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=salowey-net.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U4FVyNaiuT-j for <emu@ietfa.amsl.com>; Tue, 23 Jun 2020 21:07:58 -0700 (PDT)
Received: from mail-qt1-x830.google.com (mail-qt1-x830.google.com [IPv6:2607:f8b0:4864:20::830]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF1EB3A07AA for <emu@ietf.org>; Tue, 23 Jun 2020 21:07:57 -0700 (PDT)
Received: by mail-qt1-x830.google.com with SMTP id o38so686509qtf.6 for <emu@ietf.org>; Tue, 23 Jun 2020 21:07:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=salowey-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=HOVI/EZhScyXxqy5vluJkiXNZCTSQryhMuZh77NNBIQ=; b=S60tiQAEoXWLyWyqw4l/LxyjzFZmSJlaI82Ha5pzOkGumew0P+t/zy/TGAVYhxXNfp 74nLvwFJv5BhHOZqOG3OimS2j6oxnWPAjCFrZQ1OanybEKBvNcMLnYAyZG9f8Z5spzCK 3mpv0Li1mmwkFVyD4B8INqaGaTdi110sEGi9RmDBnUdcxdR11q971CRiKfQMprHteTtd N9BnYzSrhicbuwqQwcoR0DZbUU9wmcrCDRDgFcY/60q66ffxXZYYN9pF1f9efSYr8eI1 nzAAINr03BMA79lUbSaGKoTwJgh3xFDO/38IysH9mSjproko0on9Z695N+mA+BwQyCKi 4GkQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=HOVI/EZhScyXxqy5vluJkiXNZCTSQryhMuZh77NNBIQ=; b=GARJ7MgG4Sh7hQX9dHXCEmJfEaDG1bEDvDXMUj+5/C/45A9t09i5f1qcrA3p73qm8m KVPuNt2pRK+zV3YV2Y/2oolrqvgO32JQIrq2/WG5iKP4jWq8To7qVcmZZQ/5oGDLtP/C wQttetiBsiDtHjZ7n2fLSNYw56+An78PjBw+JxduCIoZ5uM9DiYlnt2EmH/T09LBcXBY Ry3nRiEOQ9ztKUvBA6AAaPlxHmDAL9Ea8bCtZP3zYzuIk5Jr/pnJMUQ/eenpXQLvw77t MQY1mk0oKJ+d0CFrwSSW3kqC86EU9i2ilUX1vqVESVelpxDINyWIu4MVqBF2nUqkEwBs hW8w==
X-Gm-Message-State: AOAM532nPLIKGZozECBvbTIKeF41zGNYGAJgPPKY8w0Q7X19beAny/zJ CXIMkBeyv1jsxZApSeE6wi9g2rRsaV4UfWA6C4de9g==
X-Google-Smtp-Source: ABdhPJxMVCRJTaB65vkRj8dtYtfUQQ7bmxSafnOeHUD2fvxp3o88D9CbsI6NJv/66vShnegq1Cl/Ps4mc2rbFVYT78w=
X-Received: by 2002:ac8:4718:: with SMTP id f24mr23285316qtp.95.1592971676762; Tue, 23 Jun 2020 21:07:56 -0700 (PDT)
MIME-Version: 1.0
References: <B6DEC01B-E5D0-4CC1-B9DC-CDEB567F1C53@deployingradius.com> <CH2PR21MB13815FE61D6FEE18DADA9AF0D1C30@CH2PR21MB1381.namprd21.prod.outlook.com> <CABXxEz9=ReWcB79yEZjdDcLqzYmC50+yZyqgtRvpV4vQmFEuDg@mail.gmail.com> <20200416102445.GA8757@w1.fi> <CH2PR21MB1381451B1FC4A680A37A22EFD1D40@CH2PR21MB1381.namprd21.prod.outlook.com> <CABXxEz8_2Deq90xApM_6_c-sT+m5Bvu8R=+txc5JysM-O+mSzA@mail.gmail.com> <CAOgPGoCT=uTAT=WaZCM3b_nhzxqywiMcUHyuZoo3tKzc2k5QKA@mail.gmail.com> <CH2PR21MB13810828EC6E27F8EBF43E21D1940@CH2PR21MB1381.namprd21.prod.outlook.com>
In-Reply-To: <CH2PR21MB13810828EC6E27F8EBF43E21D1940@CH2PR21MB1381.namprd21.prod.outlook.com>
From: Joseph Salowey <joe@salowey.net>
Date: Tue, 23 Jun 2020 21:07:45 -0700
Message-ID: <CAOgPGoBT6nGNDqTaBhDBO=50hpRM+x5C02Y4iQBwCrAxxea0pg@mail.gmail.com>
To: Jorge Vergara <jovergar@microsoft.com>
Cc: Oleg Pekar <oleg.pekar.2017@gmail.com>, Jouni Malinen <j@w1.fi>, EMU WG <emu@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000ee5c0a05a8cc9e7f"
Archived-At: <https://mailarchive.ietf.org/arch/msg/emu/PbnUgMuE-dgKUYLmrmYOtz_HRms>
Subject: Re: [Emu] draft-dekok-emu-tls-eap-types discussion
X-BeenThere: emu@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "EAP Methods Update \(EMU\)" <emu.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/emu>, <mailto:emu-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/emu/>
List-Post: <mailto:emu@ietf.org>
List-Help: <mailto:emu-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/emu>, <mailto:emu-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 24 Jun 2020 04:08:01 -0000

On Mon, Jun 22, 2020 at 9:06 PM Jorge Vergara <jovergar@microsoft.com>
wrote:

> >[Joe] (catching up) With respect to the case that the method is an MSK
> generating mechanism and and MSK is not generated/used.  I think the
> original intention was that this case would be a protocol violation, ie if
> a method generates an MSK it should be available for crypto-binding.   I'm
> concerned that allowing the fallback to 0 MSK actually will cause a
> security vulnerability in compound binding.  Do we know if this method
> mismatch is a problem in practice?
>
>
>
> [jovergar] I agree that if a method generates an MSK it should generally
> be used for crypto-binding. But this does not eliminate the need for a
> mechanism for each party (client/server) to communicate what kind of
> crypto-binding they are sending. The client/server is free to reject the
> crypto-binding if the peer is unable to produce a crypto-binding that
> satisfies the minimum policy of the implementation.
>
>
>
For example, if EAP-TLS is used as an inner method, and a client sends a
> zero-MSK, I would fully expect the server to reject the connection – not
> fallback to zero-MSK. I would expect a client to have similar minimum
> security policies it would accept for each method.
>
>
>
[Joe] I agree that there will be some policy needed on the client and
server, but I think the policy for this specific case (method supports MSK
but it is not used)  could be built into the protocol and simplify things.


> As to whether method mismatch is a problem in practice – yes, to an
> extent. Windows does not generate EMSK for EAP-TLS despite it being
> specified in the RFC, so the crypto-binding sent to the server is MSK
> based. If a server’s policy requires EMSK, then Windows can’t connect. This
> is certainly a Windows feature gap – but servers are free to decline the
> connection if they do not want to downgrade to an MSK based crypto binding.
>

[Joe] Yes, and I'm sure this is not the only case where EMSK is defined for
a method but not implemented.  While it would be better if everyone
implemented and used the EMSK, the MSK is better than using 0.   I agree
clients and servers will need some policy in this case.  The policy does
complicate the protocol and implementation.


>
> *From:* Joseph Salowey <joe@salowey.net>
> *Sent:* Monday, June 22, 2020 8:53 PM
> *To:* Oleg Pekar <oleg.pekar.2017@gmail.com>
> *Cc:* Jorge Vergara <jovergar@microsoft.com>; Jouni Malinen <j@w1.fi>;
> EMU WG <emu@ietf.org>
> *Subject:* Re: [Emu] draft-dekok-emu-tls-eap-types discussion
>
>
>
>
>
>
>
> On Tue, Apr 21, 2020 at 11:02 AM Oleg Pekar <oleg.pekar.2017@gmail.com>
> wrote:
>
> >And focusing on that "what to do here.." part and the unused IMCK-zero[j]
> in the previous paragraph..
> >How is this supposed to work when an inner EAP authentication method does
> not derive either MSK or EMSK?
> >Intermediate result indication of success needs to be done and that
> implies there needs to be Crypto-Binding TLV.
> >But that TLV does not have option of indicating that neither EMSK
> Compound MAC nor MSK Compound MAC are present (Flags field has no value 0
> defined to do so).
> I agree the 0 value should be explicitly listed for this purpose. Given
> the design of the flags I think it is clear this was the intended usage and
> its omission was likely an oversight.
> >So what are those fields (or one of them) supposed to be set to?
> >And how is that selected for an inner EAP authentication method j?
> >Does this depends on what happened with method j-1 (if one was present)?
> >How would the correct IMCK[j] be determined by the peer and the server if
> one of them derived MSK/EMSK but the other one did not derive either for
> inner EAP method j?
> Assuming we use the value 0 to indicate the state where one of the peers
> did not derive either MSK or EMSK, then I believe the RFC addresses this as
> MSKi = 32 octets of 0x00s. So if one side calculated neither MSK nor EMSK,
> and both sides decided to continue the conversion, then both sides would
> use the zero-MSK for that IMSK[j],
>
> Jorge, Jouni, agree with the approach.
>
>
>
> Jorge, please note that the same problem exists in PEAP Crypto-Binding TLV
> as specified in its documentation
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.microsoft.com%2Fen-us%2Fopenspecs%2Fwindows_protocols%2Fms-peap%2Febb2b12b-cd53-4f3a-afed-36588566c7c2&data=02%7C01%7Cjovergar%40microsoft.com%7Cf691061f596040be882d08d81728fe5f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637284812133625099&sdata=9B%2BrGF9AduXXuERXbDh4tTTT4I%2BnVjOI1GrLwWJNPkY%3D&reserved=0>
> - when one side has an inner method that provided MSK and another side has
> this inner method that didn't provide MSK.
>
>
>
> [Joe] (catching up) With respect to the case that the method is an MSK
> generating mechanism and and MSK is not generated/used.  I think the
> original intention was that this case would be a protocol violation, ie if
> a method generates an MSK it should be available for crypto-binding.   I'm
> concerned that allowing the fallback to 0 MSK actually will cause a
> security vulnerability in compound binding.  Do we know if this method
> mismatch is a problem in practice?
>
>
>
> There is also a case where no inner method is executed. For example, when
> client certificate was received during TEAP outer tunnel establishment. In
> this case we also need to use zero-MSK. For such case both values of the
> flag work - "0 for zero-MSK" and "2 for MSK". This creates unnecessary
> ambiguity and thus would be better to request using flag's value "0" for
> zero MSK in such case (today we use value "2" and it doesn't create
> ambiguity). However there's a question here: in case of TEAP certificate
> based authentication that is typically done by running inner method
> EAP-TLS, should we allow in sending client certificate during TEAP tunnel
> establishment or inside the tunnel and this way skipping EAP-TLS inner
> method? On one hand it makes authentication shorter. On the other hand it
> causes switching from MSK/EMSK exported by the inner method EAP-TLS to
> zero-MSK.
>
>
>
> If we do allow skipping any inner method then we need explicitly say that
> zero-MSK should be used in such case.
>
>
>
> I've started rebuilding section "*5.2*
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Frfc7170%23section-5.2&data=02%7C01%7Cjovergar%40microsoft.com%7Cf691061f596040be882d08d81728fe5f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637284812133635093&sdata=7xmEq1rNHYSq7qqa%2FSt4Z4XESqCc2FXTy%2F5X8Kob%2FBg%3D&reserved=0>*.
> Intermediate Compound Key Derivations" *of the RFC according to the
> proposal on this thread and will post it here shortly.
>
>
>
> ~ Oleg
>
>
>
>
>
>
>
>
>
> On Mon, Apr 20, 2020 at 3:57 AM Jorge Vergara <jovergar@microsoft.com>
> wrote:
>
> >And focusing on that "what to do here.." part and the unused IMCK-zero[j]
> in the previous paragraph..
> >How is this supposed to work when an inner EAP authentication method does
> not derive either MSK or EMSK?
> >Intermediate result indication of success needs to be done and that
> implies there needs to be Crypto-Binding TLV.
> >But that TLV does not have option of indicating that neither EMSK
> Compound MAC nor MSK Compound MAC are present (Flags field has no value 0
> defined to do so).
>
> I agree the 0 value should be explicitly listed for this purpose. Given
> the design of the flags I think it is clear this was the intended usage and
> its omission was likely an oversight.
>
> >So what are those fields (or one of them) supposed to be set to?
> >And how is that selected for an inner EAP authentication method j?
> >Does this depends on what happened with method j-1 (if one was present)?
> >How would the correct IMCK[j] be determined by the peer and the server if
> one of them derived MSK/EMSK but the other one did not derive either for
> inner EAP method j?
>
> Assuming we use the value 0 to indicate the state where one of the peers
> did not derive either MSK or EMSK, then I believe the RFC addresses this as
> MSKi = 32 octets of 0x00s. So if one side calculated neither MSK nor EMSK,
> and both sides decided to continue the conversion, then both sides would
> use the zero-MSK for that IMSK[j],
>
> Jorge Vergara
>
> -----Original Message-----
> From: Jouni Malinen <j@w1.fi>
> Sent: Thursday, April 16, 2020 3:25 AM
> To: Oleg Pekar <oleg.pekar.2017@gmail.com>
> Cc: Jorge Vergara <jovergar@microsoft.com>; EMU WG <emu@ietf.org>
> Subject: Re: [Emu] draft-dekok-emu-tls-eap-types discussion
>
> On Wed, Apr 15, 2020 at 07:25:08PM +0300, Oleg Pekar wrote:
> > For TEAP errata 5770:
> > Technically TEAP RFC suggests the implicit method of taking the
> > correct IMSK[j] and all the subsequent keys after each inner method
> > via negotiation taking place in Crypto-Binding TLV exchange.
>
> What is "the correct IMSK[j]" and where is this defined?
>
> > Let's say we are on the inner method number j that supports both MSK
> > and EMSK and we are server which implementation generates both MSK and
> > EMSK for this inner method. We generated keys according to the rules
> > below - two sets, for IMSK[j] derived from inner method EMSK and for
> > IMSK[j] equal to inner method MSK. Because we don't know whether
> > client implementation supports both MSK and EMSK.
> >
> > S-IMCK[0] = session_key_seed
> >       For j = 1 to n-1 do
> >            IMCK[j] = TLS-PRF(S-IMCK[j-1], "Inner Methods Compound Keys",
> >                 IMSK[j], 60)
> >            S-IMCK[j] = first 40 octets of IMCK[j]
> >            CMK[j] = last 20 octets of IMCK[j]
> >
> >
> > So we have two CMK[j] and we create Crypto-Binding TLV with both
> > Compound MAC for MSK and EMSK. The client sends Crypto-Binding TLV in
> > response and we can understand from it whether it supports EMSK for
> > this inner method or not. And here we can decide which version of
> > IMCK[j] to take for this inner method - derived from EMSK or MSK. This
> > is just not explicitly specified in the RFC.
>
> Is this the proposed definition of "the correct IMSK[J]"? In other words,
> is this to be understood to have two (or three since we have the no
> MSK/EMSK case as well) variants of IMSK[j] during an execution of an
> internal AP authentication method and a single one of those variants is
> selected as _the correct_ IMSK[j] at the successful conclusion of this
> inner authentication method?
>
> Would this single "correct IMSK[j]" then be used for deriving the
> different variants of IMSK[j+1] instead of using EMSK-based-IMSK[j] when
> deriving EMSK-based-IMSK[j+1]? In other words, is this to work by having
> all following inner authentication rounds and MSK/EMSK derivation to behave
> as if the other variants of IMSK[j] never really existed?
>
> > Could this method work? Should we make it more clearly specified? Or
> > should we change the protocol to arrive explicitly to the
> > understanding which type
> > (MSK/EMSK) of IMSK[j] to use?
>
> Regardless of what is done for the design, it will absolutely need to be
> specified more clearly.
>
> If I understood the proposed design correctly, this should be defined with
> something like following:
>
> For each successful inner EAP authentication method, derive IMCK-MSK[j]
> (if MSK was derived by the inner method), derive IMCK-EMSK[j] (if EMSK was
> derived by the inner method), derive IMSK-zero[j] (for all cases). Derive
> CMK-MSK[j] from IMCK-MSK[j] and CMK-EMSK[j] from IMCK-EMSK[j] (both: if
> available). Generate Crypto-Binding TLV with all available Compound MAC
> values. Also verify Crypto-Binding TLV with all available Compound MAC
> values. After both ends have transmitted and received Crypto-Binding TLV,
> set IMSK[j] to be IMCK-EMSK[j] if both ends included EMSK Compound MAC, or
> set IMSK[j] to be IMCK-MSK[j] if both ends included MSK Compound MAC but
> either end did not include EMSK Compound MAC, or <what to do here or can
> this even happen?>. Set S-IMCK[j] based on this IMSK[j]. This results in
> there being only a single S-IMCK[j] and MSK/EMSK derivation being well
> defined.
>
> And focusing on that "what to do here.." part and the unused IMCK-zero[j]
> in the previous paragraph.. How is this supposed to work when an inner EAP
> authentication method does not derive either MSK or EMSK? Intermediate
> result indication of success needs to be done and that implies there needs
> to be Crypto-Binding TLV. But that TLV does not have option of indicating
> that neither EMSK Compound MAC nor MSK Compound MAC are present (Flags
> field has no value 0 defined to do so).
> So what are those fields (or one of them) supposed to be set to? And how
> is that selected for an inner EAP authentication method j? Does this
> depends on what happened with method j-1 (if one was present)? How would
> the correct IMCK[j] be determined by the peer and the server if one of them
> derived MSK/EMSK but the other one did not derive either for inner EAP
> method j?
>
> --
> Jouni Malinen                                            PGP id EFC895FA
>
> _______________________________________________
> Emu mailing list
> Emu@ietf.org
> https://www.ietf.org/mailman/listinfo/emu
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Femu&data=02%7C01%7Cjovergar%40microsoft.com%7Cf691061f596040be882d08d81728fe5f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637284812133635093&sdata=sJ8Kt2EB%2Fj4fa8bErJvVs3koLowqr%2FD0LsOEB2wiwN8%3D&reserved=0>
>
>