Re: [Emu] [TLS] Fwd: Benjamin Kaduk's Discuss on draft-ietf-emu-eap-tls13-13: (with DISCUSS and COMMENT)

[Joseph Salowey]

On Tue, Jan 5, 2021 at 8:31 AM Alan DeKok  wrote:

> On Jan 5, 2021, at 11:13 AM, Mohit Sethi M 
> wrote:
> >
> > Hi Alan,
> >
> > Cleaning up the email. The current draft says the exporter should be
> called once as:
> >
> >>Key_Material = TLS-Exporter("EXPORTER_EAP_TLS_Key_Material",
> >>Type-Code, 128)
> >>
> > and then split the 128 into MSK (64) and EMSK (64). As said, from
> initial glance, it seems the exporter is called twice (once in
> eap_tls_get_emsk and once in eap_tls_getKey). Both the calls are with
> exactly the same context, context length, and labels. In getKey, the EMSK
> parts are cleared with
> >> os_memset(eapKeyData + EAP_TLS_KEY_LEN, 0, EAP_EMSK_LEN);
> > while in get_emsk, they are read with
> >
> >
> >>  os_memcpy(emsk, eapKeyData + EAP_TLS_KEY_LEN,
> >>
> >>
> >> EAP_EMSK_LEN);
> > Maybe we can live with this. But if exporter is called twice, we should
> use different labels as suggested by Martin?
>
>   Yes.
>
>   Perhaps as Joe suggested: EXPORTER_EAP_TLS_MSK and
> EXPORTER_EAP_TLS_EMSK, which seem simple enough.
>
> [Joe] I created a pull request (
https://github.com/emu-wg/draft-ietf-emu-eap-tls13/pull/17)  with the
proposed labels.  Is this change going to cause significant problems for
implementation?


>   Alan DeKok.
>
> ___
> TLS mailing list
> t...@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] [TLS] Fwd: Benjamin Kaduk's Discuss on draft-ietf-emu-eap-tls13-13: (with DISCUSS and COMMENT)

[Joseph Salowey]

On Tue, Jan 5, 2021 at 8:14 AM Mohit Sethi M  wrote:

> Hi Alan,
> Cleaning up the email. The current draft says the exporter should be
> called once as:
>
>Key_Material = TLS-Exporter("EXPORTER_EAP_TLS_Key_Material",
>Type-Code, 128)
>
> and then split the 128 into MSK (64) and EMSK (64). As said, from initial
> glance, it seems the exporter is called twice (once in eap_tls_get_emsk and
> once in eap_tls_getKey). Both the calls are with exactly the same context,
> context length, and labels. In getKey, the EMSK parts are cleared with
>
> os_memset(eapKeyData + EAP_TLS_KEY_LEN, 0, EAP_EMSK_LEN);
>
> while in get_emsk, they are read with
>
>   os_memcpy(emsk, eapKeyData + EAP_TLS_KEY_LEN,
> EAP_EMSK_LEN);
>
> Maybe we can live with this. But if exporter is called twice, we should
> use different labels as suggested by Martin?
>
> Regarding the Enc-Recv-Key and Enc-Send-Key, you obviously know more. I
> was thrown off by Joe's comment "The mechanism for splitting the MSK into
> Enc-RECV-Key and Enc-SNED-Key I believe is only used in specific legacy
> cases (WEP, MPPE?)" and the fact that other EAP methods only export MSK.
> Other EAP methods leave it to the AAA architecture for splitting up the
> MSK. Why should EAP-TLS be different?
>
[Joe] EAP TLS was defined before the keying framework so it
explicitly called out those keys.  Originally, there were RADIUS attributes
for carrying send key and receive key material defined for MPPE.  These
were reused to carry key material when WEP was integrated with 802.1x/EAP.
 With 802.11i and the EAP revision things were made more formal and the MSK
was defined, but the same RADIUS attributes were used for key transport.
Essentially, 802.11i takes the First half of the MSK and uses it as the PMK
for the 4-way handshake, this is transported to the authenticator in the
ms-mppe-recv-key attribute.   The second half of the key is sent in the
ms-mppe-send-key attribute and may be used by some other IEEE
specifications.   Newer attributes have been developed for key transport in
RADIUS over the years.  I don't know their adoption rate at this
point.  THe EMSK was developed as a key that was shared between the AAA
(EAP Server) and supplicant (EAP-Peer) that is not known to the
EAP-Authenticator.   We could leave the definition of how to derive the
receive and send keys from the MSK in the EAP-TLS spec and reference it
from this one.  Or we could just include it.



> --Mohit
> ___
> Emu mailing list
> Emu@ietf.org
> https://www.ietf.org/mailman/listinfo/emu
>
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] [TLS] Fwd: Benjamin Kaduk's Discuss on draft-ietf-emu-eap-tls13-13: (with DISCUSS and COMMENT)

[Joseph Salowey]

On Mon, Jan 4, 2021 at 6:08 AM Alan DeKok  wrote:

> On Jan 3, 2021, at 10:44 PM, Martin Thomson  wrote:
> > # Key Schedule
> >
> > The other thing I observe is the way that this slices up the exporter
> output.  This was something that old versions of TLS did, but TLS 1.3 did
> away with.  Though RFC 5216 did this, EAP-TLS for TLS 1.3 doesn't need to.
> This could - and should - do the same.  All it means is having more
> exporter labels.
>
>   That's easy enough to change at this state.  The question is what are
> those labels?

  And, we're getting very close to needing an implementation soon.  RFC
> 8446 is over two years old.  Web services have started serious migration to
> TLS 1.3.  But we still don't even have a standard for EAP.  I suggest that
> this is an issue.
>
>   At this point, we have inter-operability of TLS 1.3 for EAP-TLS, with
> the major EAP peer / server implementations.  This code is alpha, and not
> in any major release.  But we need to decide fairly soon what we're doing,
> as testing and releases take time.
>
>   The alternative is to dither around for another year or two, all the
> while relying on legacy TLS versions for 802.1X / WiFi authentication.
> i.e. packets which are trivially monitored by anyone with a WiFi card.
>
> > I appreciate that this uses exporters now rather than abusing the
> internal PRF.  That's good.  The next step is to dispense with the
> intermediate values (Key_Material, MSK, EMSK, IV) and all the slicing that
> occurs and use the TLS exporter for each of the six values that the
> protocol requires.  I also note that the 0x0D value is used multiple times,
> unnecessarily, both as a context strong to the exporter and as a prefix to
> the session ID.
>
>   If EAP-TLS was the only TLS-based EAP method, I would agree with you.
> But it's not.  Historically, each TLS-based EAP method uses it's own key
> derivations, using method-specific strings.  This practice made
> implementations more difficult and error-prone.
>

[Joe] It may be worth having separate exporter tags for EMSK and MSK.
(EXPORTER_EAP_TLS_MSK
and EXPORTER_EAP_TLS_EMSK).   I believe current applications define the use
EAP key material based on the MSK or EMSK.   The mechanism for splitting
the MSK into Enc-RECV-Key and Enc-SNED-Key I believe is only used in
specific legacy cases (WEP, MPPE?) and may still be the radius attributes
used in some deployments, so I don't think we should alter that
derivation.   I'm not sure where the IV is used, but I don't think
splitting it up more will be helpful.


>
>   The use of 0x0D is to allow standard key derivations across TLS-based
> EAP methods.  The other methods replaced the 0x0D byte with their own EAP
> type value.  This practice greatly simplifies implementations.
>
>   See https://tools.ietf.org/html/draft-dekok-emu-tls-eap-types-00 for
> more information.
>
>   Alan DeKok.
>
> ___
> Emu mailing list
> Emu@ietf.org
> https://www.ietf.org/mailman/listinfo/emu
>
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] [TLS] Fwd: Benjamin Kaduk's Discuss on draft-ietf-emu-eap-tls13-13: (with DISCUSS and COMMENT)

[Joseph Salowey]

Hi Martin,

Thanks for taking a look at this, some comments below:

On Sun, Jan 3, 2021 at 7:45 PM Martin Thomson  wrote:

> Hi All,
>
> Ben asked me to take a look at this draft and I think that the general
> gist of Ben's comments need some careful consideration.
>
> # Commitment Message
>
> I think that Ben's concerns about the Commitment Message are justified,
> but aren't as bad a layering violation as observed (almost).  It would be
> annoying and difficult to implement this correctly, but not impossible.
> We've done much worse in QUIC.
>
> However, it would be much better not to include the Commitment Message at
> all.
>
> In addition to the reasons Ben describes, I have a much simpler one: the
> EAP layer has a signal that the protocol is complete: EAP-Success.  The
> only thing that the Commitment Message adds to that is a very narrow form
> of authentication.  The cost of that authentication is fairly significant,
> as Ben identifies, but what it gets you is a strong assurance that the
> messages preceding it were not truncated.
>
> As both entities have to verify that the TLS handshake was successfully
> completed independent of any EAP signals, the only thing the Commitment
> Message provides is the assurance that an attacker didn't insert or remove
> any post-handshake messages.  Any inserted messages would still need to be
> authentic, so given that a server won't send stuff it isn't permitted to
> (unless it likes failures), the exposure is minimal.  The only real
> "attack" I can see based on the current design is the removal of
> NewSessionTicket.  The effect of that attack is limited to denying the
> client access to resumption.  This is something we live with in other TLS
> usage contexts; EAP can probably manage too.
>
> The draft does not attempt to apply similar protection to client messages,
> despite having the same theoretical problem.
>
> I also think that the idea that you might get a TLS Alert after declaring
> success is odd.  I don't see any cause to keep the TLS session active after
> declaring success.  I would also remove EAP-Failure (for TLS reasons at
> least) after EAP-Success from the state machine.  TLS state can be
> discarded once EAP-{Success|Failure} is sent and received.
>
> I would instead either prohibit the use of application data outright or
> say that it carries no semantics unless otherwise negotiated.  The current
> design has the effect of rendering application data unusable, so perhaps
> the former is best.
>
>
[Joe] I'm not sure I remember correctly, but I think the commitment message
was to make the integration with EAP statement machine cleaner and perhaps
to future proof against additional messages sent after the handshake.  I
tend to agree that the value is low in the current situation (It is a
deviation from RFC 5216).   Given all the discussion this message has
caused I'm tempted to agree that we should just remove it (or make it
"optional" in case implementations already do this).  There may need to be
some text in the draft that says the NewSessionTicketMessage must be sent
in the same flight as the finished message. I'd like to understand if there
is an implementation consideration that requires the commitment message.


> # Key Schedule
>
> The other thing I observe is the way that this slices up the exporter
> output.  This was something that old versions of TLS did, but TLS 1.3 did
> away with.  Though RFC 5216 did this, EAP-TLS for TLS 1.3 doesn't need to.
> This could - and should - do the same.  All it means is having more
> exporter labels.
>
> I appreciate that this uses exporters now rather than abusing the internal
> PRF.  That's good.  The next step is to dispense with the intermediate
> values (Key_Material, MSK, EMSK, IV) and all the slicing that occurs and
> use the TLS exporter for each of the six values that the protocol
> requires.  I also note that the 0x0D value is used multiple times,
> unnecessarily, both as a context strong to the exporter and as a prefix to
> the session ID.
>
> [Joe]  I can see your point, but I don't think the way the keys are
derived is wrong and don't really see the need to change it at this point.


> # Editorial Nits
>
> I found the way that this updates RFC 5216 to be extremely difficult to
> process.  Section 2.1.4 (which updates Section 2.1.3...) is particularly
> nasty to read.
>
> RFC 5216 is a short document; obsoleting it completely would have been my
> preferred approach.  There is enough new material in this document that
> applies to TLS 1.2 as well as TLS 1.3 to justify a revision rather than a
> patch.
>
> [Joe] yes, however I think the agreement during the chartering was that it
would just update and not obsolete RFC 5216.


> Section 5.4 "EAP--TLS" has two hyphens.
>
> On Thu, Dec 17, 2020, at 09:38, Benjamin Kaduk wrote:
> > Hi TLS WG,
> >
> > I'm forwarding my ballot comments on the (now-deferred) EAP with TLS 1.3
> > draft here, since they relate to some rather core TLS protocol 

Re: [Emu] Revised resolution for TEAP erratum 5127

[Joseph Salowey]

At the IETF 109 EMU meeting Oleg suggest that we make it clear that if an
MSK is generated it must be used.  I suggest we do this by updating this
revision as below:

Section 5.2 says

 IMSK = First 32 octets of TLS-PRF(EMSK, "teapbind...@ietf.org" |
 "\0" | 64)

 where "|" denotes concatenation, EMSK is the EMSK from the inner
 method, "teapbind...@ietf.org" consists the ASCII value for the
 label "teapbind...@ietf.org" (without quotes), "\0" = is a NULL
 octet (0x00 in hex), length is the 2-octet unsigned integer in
 network byte order, and TLS-PRF is the PRF negotiated as part of
 TLS handshake [RFC5246].

 If an inner method does not support export of an Extended Master
 Session Key (EMSK), then IMSK is the MSK of the inner method.  The
 MSK is truncated at 32 octets if it is longer than 32 octets or
 padded to a length of 32 octets with zeros if it is less than 32
 octets.

It should say:

 IMSK = First 32 octets of TLS-PRF(EMSK, "teapbind...@ietf.org",
 0x00 | 0x00 | 0x40)

 where "|" denotes concatenation and the TLS-PRF is defined in
 [RFC5246] as

 PRF(secret, label, seed) = P_(secret, label | seed).

 the secret is the EMSK from the inner method, the label is
 "teapbind...@ietf.org" consisting of the ASCII value for the
 label "teapbind...@ietf.org" (without quotes),  the seed
 consists of the "\0" null delimiter (0x00) and 2-octet unsigned
 integer length in network byte order (0x00 | 0x4) specified
 in [RFC5295].

 If an inner method does not support export of an Extended Master
 Session Key (EMSK), then the IMSK MUST be derived from the
 MSK of the inner method.  The MSK is truncated at 32
 octets if it is longer than 32 octets or padded to a length of 32
 octets with zeros if it is less than 32 octets.

Cheers,

Joe



On Thu, Oct 29, 2020 at 10:05 PM Joseph Salowey  wrote:

> I think this erratum is done. I've also started a GH repo to track the
> changes in the document which might help show them in context a bit better.
> The PR for this issue is https://github.com/emu-wg/teap-errata/pull/2.
> Please post here or comment on the PR if you think this needs any
> additional work.
>
> Errata 5127: https://www.rfc-editor.org/errata/eid5127
> Proposed State: Verified
> Revision: https://github.com/emu-wg/teap-errata/pull/2
> Section 5.2 says
>
>  IMSK = First 32 octets of TLS-PRF(EMSK, "teapbind...@ietf.org" |
>  "\0" | 64)
>
>  where "|" denotes concatenation, EMSK is the EMSK from the inner
>  method, "teapbind...@ietf.org" consists the ASCII value for the
>  label "teapbind...@ietf.org" (without quotes), "\0" = is a NULL
>  octet (0x00 in hex), length is the 2-octet unsigned integer in
>  network byte order, and TLS-PRF is the PRF negotiated as part of
>  TLS handshake [RFC5246].
>
> It should say:
>
>  IMSK = First 32 octets of TLS-PRF(EMSK, "teapbind...@ietf.org",
>  0x00 | 0x00 | 0x40)
>
>  where "|" denotes concatenation and the TLS-PRF is defined in
>  [RFC5246] as
>
>  PRF(secret, label, seed) = P_(secret, label | seed).
>
>  the secret is the EMSK from the inner method, the label is
>  "teapbind...@ietf.org" consisting of the ASCII value for the
>  label "teapbind...@ietf.org" (without quotes),  the seed
>  consists of the "\0" null delimiter (0x00) and 2-octet unsigned
>  integer length in network byte order (0x00 | 0x4) specified
>  in [RFC5295].
>
> Notes:
>
> RFC5246 The Transport Layer Security (TLS) Protocol Version 1.2
> 5. HMAC and the Pseudorandom Function
>
> "TLS's PRF is created by applying P_ to the secret as:
>
> PRF(secret, label, seed) = P_(secret, label + seed)"
>
> In this case the seed is the 2-byte length of the output as defined by RFC
> 5295. In terms of P_ the derivation would look like:
>
> IMSK = P_(EMSK, "teapbind...@ietf.org" | 0x00 | 0x00 | 0x40)
>
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] Proposed Resolution for TEAP errata 5768

[Joseph Salowey]

On Thu, Nov 19, 2020 at 8:53 PM Jorge Vergara 
wrote:

> Sorry for the last minute comment on this one before the meeting. I would
> like to mark this as a “discuss” - I have some compat concern about making
> the TLV length variable. Current implementations truncate the MAC field at
> 20 octets. Although I agree in spirit with the direction of this change, I
> think it would require changing the version of the Crypto-Binding TLV.
>
>
>
> I recognize that most probably won’t have time to review this concern
> before the meeting and so the discussion may not be able to occur there.
> Apologies again as I only realized this concern as I was giving everything
> a final pass-over.
>
>
>

[Joe] Thanks for catching this.  If this is the case then we should have
the errata resolution reflect what implementations do and leave the rest of
the change for a document update.

For this I suggest that we leave section 4.2.13 unchanged and make changes
to 5.3.

Section 5.3 Says:



 The Compound MAC computation is as follows:

  CMK = CMK[j]
  Compound-MAC = MAC( CMK, BUFFER )

   where j is the number of the last successfully executed inner EAP
   method, MAC is the MAC function negotiated in TLS 1.2 [RFC5246], and
   BUFFER is created after concatenating these fields in the following
   order:

   1  The entire Crypto-Binding TLV attribute with both the EMSK and MSK
  Compound MAC fields zeroed out.

   2  The EAP Type sent by the other party in the first TEAP message.



It Should say:



 The Compound MAC computation is as follows:

  CMK = CMK[j]
  Compound-MAC = MAC( CMK, BUFFER )

   where j is the number of the last successfully executed inner EAP
   method, MAC is HMAC [RFC2104] using the hash function negotiated in

   TLS [RFC5246].  If the output of the HMAC is greater than 20 bytes then

   it is truncated to 20 bytes.  The BUFFER is created after concatenating

   these fields in the following order:


   1  The entire Crypto-Binding TLV attribute with both the EMSK and MSK
  Compound MAC fields zeroed out.

   2  The EAP Type sent by the other party in the first TEAP message. This

   is a single octet encoded as (0x37)


> Jorge Vergara
>
>
>
> *From:* Oleg Pekar 
> *Sent:* Saturday, October 24, 2020 4:30 PM
> *To:* Joseph Salowey 
> *Cc:* EMU WG ; Jouni Malinen ; Jorge Vergara <
> jover...@microsoft.com>
> *Subject:* Re: Proposed Resolution for TEAP errata 5768
>
>
>
> > 2  The EAP Type sent by the other party in the first TEAP message. This
> is a single octet encoded as (0x37)
>
>
>
> Shouldn't we clarify the motivation for placing the octet with TEAP type
> 0x37 into the BUFFER? Joe, I remember you explained that it is for
> protection against cross protocol attacks if Crypto-Binding TLV was reused
> (e.g. from PEAP).
>
>
>
> On Sun, Oct 25, 2020 at 12:45 AM Joseph Salowey  wrote:
>
> Errata 5768:  https://www.rfc-editor.org/errata/eid5768
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Ferrata%2Feid5768=04%7C01%7Cjovergar%40microsoft.com%7C100b027d04c14dc5f59b08d87874b568%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637391789943190120%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000=jn7e%2FfR9O%2Fa%2B%2F1gPWuUcUaXKKyf%2F8cTAR0qTXXx6MRM%3D=0>
>
> Proposed State: Verified
>
> Revision:
>
>
>
> Section 4.2.13. Says:
>
>
>
> Length
>
>
>
> 76
>
>
>
> It should say:
>
>
>
> Length
>
>
>
>  36 plus the length of the 2 MAC fields
>
>
>
> Section 4.2.13. Says:
>
>
>EMSK Compound MAC
>
>   The EMSK Compound MAC field is 20 octets.  This can be the Server
>   MAC (B1_MAC) or the Client MAC (B2_MAC).  The computation of the
>   MAC is described in Section 5.3.
>
>MSK Compound MAC
>
>   The MSK Compound MAC field is 20 octets.  This can be the Server
>   MAC (B1_MAC) or the Client MAC (B2_MAC).  The computation of the
>   MAC is described in Section 5.3.
>
>
>
> It Should Say:
>
>
>
>EMSK Compound MAC
>
>   The computation of the MAC is described in Section 5.3.  This can be
>
>   the Server MAC (B1_MAC) or the Client MAC (B2_MAC).
>
>MSK Compound MAC
>
>   The computation of the MAC is described in Section 5.3.  This can be
>
>   the Server MAC (B1_MAC) or the Client MAC (B2_MAC).
>
>
>
> Section 5.3 Says:
>
>
>
>  The Compound MAC computation is as follows:
>
>   CMK = CMK[j]
>   Compound-MAC = MAC( CMK, BUFFER )
>
>where j is the number of the last successfully executed inner EAP
>method, MAC is the MAC function negotiated in TLS 1.2 [RFC5246

[Emu] Working Group Last Call for draft-ietf-emu-eap-noob-02

[Joseph Salowey]

At  IETF 109 meeting there was support for moving EAP-NOOB forward.  The
chairs and authors believe the document is ready to progress so this starts
the working group last call for EAP-NOOB [1].   Please review the document
and send comments to the list by December 11, 2020.  Statements of support
or opposition are welcome especially if accompanied with reasons for the
position.

Thanks,

Joe

[1] https://datatracker.ietf.org/doc/draft-ietf-emu-eap-noob/
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

[Emu] EMU at IETF 109

[Joseph Salowey]

If you are presenting at IETF 109 tomorrow please send your slides to the
chairs.

Friday, November 20, 2020 12:00 - 14:00 (+07)

Agenda 
Meeting Information

   1.

   Participants Guide
   

   https://www.ietf.org/how/meetings/109/session-participant-guide/
   2.

   Meetecho Link
   

   https://meetings.conf.meetecho.com/ietf109/?group=emu==1
   3.

   CodiMD Link 

   https://codimd.ietf.org/notes-ietf-109-emu
   4.

   Audio Link 

   http://mp3.conf.meetecho.com/ietf109/emu/1.m3u
   5.

   Jabber

   xmpp:e...@jabber.ietf.org?join
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] Proposed Resolution to TEAP Errata 5844

[Joseph Salowey]

On Tue, Nov 10, 2020 at 2:17 PM Oleg Pekar 
wrote:

> Section 3.3.2 says:
>> Upon receiving the response, the server
>>indicates the success or failure of the exchange using an
>>Intermediate-Result TLV.
>> It Should say:
>> Upon receiving the response, the server MUST
>>indicate the success or failure of the exchange using an
>>Intermediate-Result TLV.
>
>
>  Shouldn't it be:
>
> Upon receiving the response, the server MUST
>indicate the success or failure of the exchange using an
>Intermediate-Result TLV and Crypto-Binding TLV.
>
> Since necessity to send Crypto-Binding TLV after basic password
> authentication was already mentioned in section 4.2.13 of Errata 5775 mail
> thread.
>
>
[Joe] The crypto binding TLS is only included on a successful exchange.
section 4.2.11 says "An Intermediate-Result TLV indicating success

   MUST be accompanied by a Crypto-Binding TLV."  Maybe it should say:


"Upon receiving the response, the server MUST
   indicate the success or failure of the exchange using an
   Intermediate-Result TLV accompanied by a Crypto-Binding

   TLV if the exchange is successful."




> On Mon, Nov 2, 2020 at 12:12 AM Joseph Salowey  wrote:
>
>> Revision for 8544. The wording needs some review.  Additional revisions
>> were made to section 4.2.13 in 5775.
>>
>> PR Section 5: https://github.com/emu-wg/teap-errata/pull/19
>> PR section 3: https://github.com/emu-wg/teap-errata/pull/22
>> PR section 3: https://github.com/emu-wg/teap-errata/pull/23
>> PR section 4: https://github.com/emu-wg/teap-errata/pull/24
>>
>> Errata 5844: https://www.rfc-editor.org/errata/eid5844
>> Status: Verified
>> Revision:
>>
>> Section 3.3.2 says:
>>
>> Upon receiving the response, the server
>>indicates the success or failure of the exchange using an
>>Intermediate-Result TLV.
>>
>> It Should say:
>>
>> Upon receiving the response, the server MUST
>>indicate the success or failure of the exchange using an
>>Intermediate-Result TLV.
>>
>> Section 3.6 says:
>>
>> 3. The Intermediate-Result TLVs carry success or failure indications of
>> the individual EAP methods in TEAP Phase 2.
>>
>> It Should say:
>>
>> 3. The Intermediate-Result TLVs carry success or failure indications of
>> each individual EAP authentication method or basic password authentication
>> in TEAP Phase 2.
>>
>> Section 4.2.11 says:
>>
>> The Intermediate-Result TLV provides support for acknowledged
>> intermediate Success and Failure messages between multiple inner EAP
>> methods within EAP.
>>
>> It Should say:
>>
>> The Intermediate-Result TLV provides support for acknowledged
>> intermediate Success and Failure messages for inner EAP authentication
>> methods and basic password authentication.
>>
>> Section C.1 says:
>>
>> <- Crypto-Binding TLV (Request),
>> Result TLV (Success),
>> (Optional PAC TLV)
>>
>>Crypto-Binding TLV(Response),
>>Result TLV (Success),
>>(PAC-Acknowledgement TLV) ->
>>
>> It should say:
>>
>> <- Intermediate-Result-TLV (Success),
>> Crypto-Binding TLV (Request),
>> Result TLV (Success),
>> (Optional PAC TLV)
>>
>>Intermediate-Result-TLV (Success),
>>Crypto-Binding TLV(Response),
>>Result TLV (Success),
>>(PAC-Acknowledgement TLV) ->
>>
>> Section C.2 Says:
>> <- Result TLV (Failure)
>>
>> Result TLV (Failure) ->
>>
>> It Should Say:
>>
>> <- Intermediate-Result-TLV (Failure),
>>  Result TLV (Failure)
>>
>> Intermediate-Result-TLV (Failure),
>>Result TLV (Failure) ->
>>
>>
>> Notes:
>>
>> Section 3.3.2 implies that Intermediate-Result TLV is used after each
>> round of Basic-Password-Auth-Req/Resp TLVs. However, the example sequence
>> in C.1 does not show this. The proposed change in this errata adds the
>> Intermediate-Result TLV indication here. Similar change should be done in
>> C.2 (i.e., add Intermediate-Result TLV (Failure) to the messages that
>> include Result TLV) since the language in 3.3.2 describe the indication to
>> be used

Re: [Emu] Agenda Items for virtual IETF 109

[Joseph Salowey]

On Tue, Nov 3, 2020 at 9:40 PM Mohit Sethi M 
wrote:

> I think our slot is scheduled for 05:00 - 07:00 UTC. The times shown on
> the agenda: https://datatracker.ietf.org/meeting/109/agenda are in UTC +
> 7.
>
> [Joe] Yes that is correct, sorry for the confusion.

> --Mohit
> On 11/4/20 7:33 AM, Joseph Salowey wrote:
>
> At the virtual IETF 100 meeting, we will have a 2 hour session on
> Friday, November 20, between 12:00 - 14:00 UTC.
>
>
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

[Emu] Agenda Items for virtual IETF 109

[Joseph Salowey]

At the virtual IETF 100 meeting, we will have a 2 hour session on
Friday, November 20, between 12:00 - 14:00 UTC.

Please send the chairs (emu-cha...@ietf.org) requests for presentation
slots.

Don't forget to include the title of your presentation, related drafts,
and the approximate amount of time needed.  We will be giving priority
to items we ran out of time for at IETF 108 and to working group
items.

Joe and Mohit
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

[Emu] Proposed TEAP Errata Resolution Summary

[Joseph Salowey]

Below is the summary of the TEAP errata resolutions.  The text that will be
sent to the AD is in the linked emails.  The GitHub PR is provided to make
it easier to review the revision in context.  Anything that is marked for
final review will be sent to the AD next week if there are no objections
raised.  Ones marked discuss should have some discuss to verify the
resolution (5765, 5767, 5775, 5844).

Thanks,

Joe

Errata ID: 5127
Status: Verified - Final Review
Type: Technical
Mail: https://mailarchive.ietf.org/arch/msg/emu/R5uypu9Kna8vTpyV5BlIXDm-Mdk/
PR: https://github.com/emu-wg/teap-errata/pull/2

Errata ID: 5128
Status: Verified - Final Review
Type: Technical
Mail: https://mailarchive.ietf.org/arch/msg/emu/fYBuPgWa7xiH7JmoHfP5yrU7HV0/
PR: https://github.com/emu-wg/teap-errata/pull/4

Errata ID: 5765
Status: Verified - Discuss
Type: Technical
Mail: https://mailarchive.ietf.org/arch/msg/emu/Ga8evJZzLG8lCML-kkxV6G_JS0E/
Mail: https://mailarchive.ietf.org/arch/msg/emu/676S5r51SkmxtzLZH9FqNFB6aOQ/
PR: https://github.com/emu-wg/teap-errata/pull/18

Errata ID: 5767
Status: Hold For Document Update - Discuss
Type: Technical
Mail: https://mailarchive.ietf.org/arch/msg/emu/QIOT258m2LNCnmCGKgpjCYVFLWE/

Errata ID: 5768
Status: Verified - Final Review
Type: Technical
Mail: https://mailarchive.ietf.org/arch/msg/emu/r-nAObtWmZ6tt1Dd0fmc7cHEBNs/
PR for section 5 is: https://github.com/emu-wg/teap-errata/pull/8
PR for section 4 is: https://github.com/emu-wg/teap-errata/pull/7

Errata ID: 5770
Status: Verified - Final Review
Type: Technical
Mail: https://mailarchive.ietf.org/arch/msg/emu/mXzpSGEn86Zx_fa4f1uULYMhMoM/
PR for section 5: https://github.com/emu-wg/teap-errata/pull/13

Errata ID: 5775
Status: Verified - Discuss
Type: Technical
Mail: https://mailarchive.ietf.org/arch/msg/emu/u96Oxo2oFnsntJUFRFgiPENDcYQ/
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: 5844
Status: Verified - Discuss
Type: Technical
Mail: https://mailarchive.ietf.org/arch/msg/emu/1ceqDbGP3mozqbzZ40xo48zFiDo/

PR Section 5: https://github.com/emu-wg/teap-errata/pull/19
PR section 3: https://github.com/emu-wg/teap-errata/pull/22
PR section 3: https://github.com/emu-wg/teap-errata/pull/23
PR section 4: https://github.com/emu-wg/teap-errata/pull/24

Errata ID: 5845
Status: Verified - Final review
Type: Technical Mail:
https://mailarchive.ietf.org/arch/msg/emu/Ucy2tg7UyZFry99k3oGOY_aS6mk
The PR for section 3: https://github.com/emu-wg/teap-errata/pull/20

Errata ID: 6157
Status: Verified - Final Review
Type: Technical
Mail: https://mailarchive.ietf.org/arch/msg/emu/t1HhhUL0QFgBmgAFYRMRkKXWXaA/
PR:https://github.com/emu-wg/teap-errata/pull/21
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] Proposed Resolution for Errata 5845

[Joseph Salowey]

I think this one is ready to go.
The PR for section 3: https://github.com/emu-wg/teap-errata/pull/20

Errata 5845: https://www.rfc-editor.org/errata/eid5845
Proposed Status: Verified
Revision:

Section 3.3.1 says:

   EAP method messages are carried within EAP-Payload TLVs defined in
   Section 4.2.10.  If more than one method is going to be executed in
   the tunnel, then upon method completion, the server MUST send an
   Intermediate-Result TLV indicating the result.

It should say:

   EAP method messages are carried within EAP-Payload TLVs defined in
   Section 4.2.10.  Upon completion of an EAP authentication method, the
   server MUST send an Intermediate-Result TLV indicating the result.

Notes:

Description of whether Intermediate-Result TLV is supposed to be used in
the case where only a single inner EAP authentication method is used.
Section 3.3.1 says "more than one method is going to be executed in the
tunnel, then upon method completion, the server MUST send an
Intermediate-Result TLV indicating the result", Section 3.3.3 says "The
Crypto-Binding TLV and Intermediate-Result TLV MUST be included to perform
cryptographic binding after each successful EAP method in a sequence of one
or more EAP methods", 4.2.13 says "It MUST be included with the
Intermediate-Result TLV to perform cryptographic binding after each
successful EAP method in a sequence of EAP methods", Annex C.3 shows an
example exchange with a single inner EAP authentication method with use of
Intermediate-Result TLV.

It looks like the majority of the places discussion this topic implies that
there is going to be an Intermediate-Result TLV after each inner EAP
authentication method and the text in 3.3.1 is the only clear case of
conflicting (or well, at least misleading if one were to claim it does not
explicitly say MUST NOT for the one inner EAP authentication method case).
As such, I'd conclude the Intermediate-Result TLV is indeed going to be
exchanged after each EAP authentication method and the proposed text change
to 3.3.1 covers that.

On Mon, Oct 26, 2020 at 8:23 PM Joseph Salowey  wrote:

>
>
> On Mon, Oct 26, 2020 at 1:27 AM Oleg Pekar 
> wrote:
>
>> >It should say:
>> >
>> >   EAP method messages are carried within EAP-Payload TLVs defined in
>> >   Section 4.2.10.  Upon method completion, the server MUST send an
>> >  Intermediate-Result TLV indicating the result.
>>
>> Jouni explained in errata 5767 that not all EAP methods are EAP
>> authentication methods, to be exact. In the proposed fix for errata 5767
>> you have already suggested that for Section 3.3.1 text:
>>
>> >Section 3.3.1
>> >
>> >It should say:
>>
>> >   EAP method messages are carried within EAP-Payload TLVs defined in
>> >   Section 4.2.10.  Upon completion of each EAP authentication method in
>> >   the tunnel, the server MUST send an Intermediate-Result TLV
>> >   indicating the result.
>>
>>
> [Joe] Yes, I think you are correct.
>
>
>>
>>
>> On Sun, Oct 25, 2020 at 9:14 PM Joseph Salowey  wrote:
>>
>>> Errata 5845: https://www.rfc-editor.org/errata/eid5845
>>> Proposed Status: Verified
>>> Revision:
>>>
>>> Section 3.3.1 says:
>>>
>>>EAP method messages are carried within EAP-Payload TLVs defined in
>>>Section 4.2.10.  If more than one method is going to be executed in
>>>the tunnel, then upon method completion, the server MUST send an
>>>Intermediate-Result TLV indicating the result.
>>>
>>> It should say:
>>>
>>>EAP method messages are carried within EAP-Payload TLVs defined in
>>>Section 4.2.10.  Upon method completion, the server MUST send an
>>>Intermediate-Result TLV indicating the result.
>>>
>>> Notes:
>>>
>>> Description of whether Intermediate-Result TLV is supposed to be used in
>>> the case where only a single inner EAP authentication method is used.
>>> Section 3.3.1 says "more than one method is going to be executed in the
>>> tunnel, then upon method completion, the server MUST send an
>>> Intermediate-Result TLV indicating the result", Section 3.3.3 says "The
>>> Crypto-Binding TLV and Intermediate-Result TLV MUST be included to perform
>>> cryptographic binding after each successful EAP method in a sequence of one
>>> or more EAP methods", 4.2.13 says "It MUST be included with the
>>> Intermediate-Result TLV to perform cryptographic binding after each
>>> successful EAP method in a sequence of EAP methods", Annex C.3 shows an
>>> example exchange with a single inner EAP authent

Re: [Emu] Proposed Resolution to TEAP Errata 5844

[Joseph Salowey]

Revision for 8544. The wording needs some review.  Additional revisions
were made to section 4.2.13 in 5775.

PR Section 5: https://github.com/emu-wg/teap-errata/pull/19
PR section 3: https://github.com/emu-wg/teap-errata/pull/22
PR section 3: https://github.com/emu-wg/teap-errata/pull/23
PR section 4: https://github.com/emu-wg/teap-errata/pull/24

Errata 5844: https://www.rfc-editor.org/errata/eid5844
Status: Verified
Revision:

Section 3.3.2 says:

Upon receiving the response, the server
   indicates the success or failure of the exchange using an
   Intermediate-Result TLV.

It Should say:

Upon receiving the response, the server MUST
   indicate the success or failure of the exchange using an
   Intermediate-Result TLV.

Section 3.6 says:

3. The Intermediate-Result TLVs carry success or failure indications of the
individual EAP methods in TEAP Phase 2.

It Should say:

3. The Intermediate-Result TLVs carry success or failure indications of
each individual EAP authentication method or basic password authentication
in TEAP Phase 2.

Section 4.2.11 says:

The Intermediate-Result TLV provides support for acknowledged intermediate
Success and Failure messages between multiple inner EAP methods within EAP.

It Should say:

The Intermediate-Result TLV provides support for acknowledged intermediate
Success and Failure messages for inner EAP authentication methods and basic
password authentication.

Section C.1 says:

<- Crypto-Binding TLV (Request),
Result TLV (Success),
(Optional PAC TLV)

   Crypto-Binding TLV(Response),
   Result TLV (Success),
   (PAC-Acknowledgement TLV) ->

It should say:

<- Intermediate-Result-TLV (Success),
Crypto-Binding TLV (Request),
Result TLV (Success),
(Optional PAC TLV)

   Intermediate-Result-TLV (Success),
   Crypto-Binding TLV(Response),
   Result TLV (Success),
   (PAC-Acknowledgement TLV) ->

Section C.2 Says:
<- Result TLV (Failure)

Result TLV (Failure) ->

It Should Say:

<- Intermediate-Result-TLV (Failure),
 Result TLV (Failure)

Intermediate-Result-TLV (Failure),
   Result TLV (Failure) ->


Notes:

Section 3.3.2 implies that Intermediate-Result TLV is used after each round
of Basic-Password-Auth-Req/Resp TLVs. However, the example sequence in C.1
does not show this. The proposed change in this errata adds the
Intermediate-Result TLV indication here. Similar change should be done in
C.2 (i.e., add Intermediate-Result TLV (Failure) to the messages that
include Result TLV) since the language in 3.3.2 describe the indication to
be used for both success and failure cases.

In addition to this change in C.1, it would be good to clarify the
specification globally to avoid confusion about this case since almost all
discussion regarding Intermediate-Result TLV currently is in the context of
inner EAP authentication. 3.3.2 should have a MUST statement similar to
3.3.1. 3.6 should cover success or failure indications of basic password
auth like it does EAP methods. 4.2.11 should note Intermediate-Result TLV
is used with both inner EAP and basic password auth.



On Mon, Oct 26, 2020 at 8:44 PM Joseph Salowey  wrote:

>
>
> On Mon, Oct 26, 2020 at 8:39 PM Joseph Salowey  wrote:
>
>>
>>
>> On Mon, Oct 26, 2020 at 1:27 AM Oleg Pekar 
>> wrote:
>>
>>> Few comments:
>>> 1) It seems that the server MUST send Crypto-Binding TLV after a single
>>> EAP authentication method, after each of EAP authentications methods in a
>>> sequence, after no inner method but not after
>>> Basic-Password-Authentication. Shouldn't we close this gap for the sake of
>>> simplicity and structure? (Only Zero-MSK Crypto-Binding TLV is possible in
>>> this case, the same as in no inner method case). Is
>>> Basic-Password-Authentication treated as a case of no inner method?
>>> Technically it is already correct but still may not be clear enough.
>>>
>>> This also affects section "4.2.13. Crypto-Binding TLV":
>>>
>>> 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.
>>>
>>> Shouldn't we mention "inner EAP method or basic password authentication"?
>>>
>>
>> [Joe] There are two cases where CryptoBinding is used, after completion
>> of an EAP authentication exchange and with the Result-TLV exchange.   Since
>> password based authentication does not generate a key there is no need for
>> crypto bi

[Emu] Revised TEAP Erratum 5770

[Joseph Salowey]

This revision removes the modification to section 5.4 to erratum 5775.  It
also leaves the discussion of the 0 MSK to a separate paragraph to be
revised in 5770.  I think this revision is ready.  Please comment on the
list or the PR if you do not think it is ready.

PR for section 5: https://github.com/emu-wg/teap-errata/pull/13

Errata ID: 5770 https://www.rfc-editor.org/errata/eid5770
Status: Verified
Type: Technical
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.

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.  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.


Notes:

This revision clarifies handling cases where the EMSK may not be available
and the MSK may not be allowed by policy.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

[Emu] Revised Erratum for 5775

[Joseph Salowey]

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

[Emu] Revised Resolution for TEAP erratum 5768

[Joseph Salowey]

This revision has small changes to the text in the length field and changes
the text that describes what j represents to the last successfully
generated IMCK.  I think this revision is ready.  Please comment on the
list or the PR if you do not think it is ready.

PR for section 5  is: https://github.com/emu-wg/teap-errata/pull/8
PR for section 4 is: https://github.com/emu-wg/teap-errata/pull/7

Errata 5768:  https://www.rfc-editor.org/errata/eid5768
Proposed State: Verified
Revision:

Section 4.2.13. Says:

Length

76

It should say:

Length

 36 plus the length of included MAC fields

Section 4.2.13. Says:

   EMSK Compound MAC

  The EMSK Compound MAC field is 20 octets.  This can be the Server
  MAC (B1_MAC) or the Client MAC (B2_MAC).  The computation of the
  MAC is described in Section 5.3.

   MSK Compound MAC

  The MSK Compound MAC field is 20 octets.  This can be the Server
  MAC (B1_MAC) or the Client MAC (B2_MAC).  The computation of the
  MAC is described in Section 5.3.

It Should Say:

   EMSK Compound MAC

  The computation of the MAC is described in Section 5.3.  This can be
  the Server MAC (B1_MAC) or the Client MAC (B2_MAC).

   MSK Compound MAC

  The computation of the MAC is described in Section 5.3.  This can be
  the Server MAC (B1_MAC) or the Client MAC (B2_MAC).

Section 5.3 Says:

 The Compound MAC computation is as follows:

  CMK = CMK[j]
  Compound-MAC = MAC( CMK, BUFFER )

   where j is the number of the last successfully executed inner EAP
   method, MAC is the MAC function negotiated in TLS 1.2 [RFC5246], and
   BUFFER is created after concatenating these fields in the following
   order:

   1  The entire Crypto-Binding TLV attribute with both the EMSK and MSK
  Compound MAC fields zeroed out.

   2  The EAP Type sent by the other party in the first TEAP message.

It Should say:

 The Compound MAC computation is as follows:

  CMK = CMK[j]
  Compound-MAC = MAC( CMK, BUFFER )

   where j is the number of the last successfully generated IMCK,
   MAC is HMAC [RFC2104] using the hash function negotiated in
   TLS [RFC5246].  The output length is the length of the output of the HMAC
   function.  The BUFFER is created after concatenating these fields in
   the following order:

   1  The entire Crypto-Binding TLV attribute with both the EMSK and MSK
  Compound MAC fields zeroed out.

   2  The EAP Type sent by the other party in the first TEAP message. This
   is a single octet encoded as (0x37)

Notes:

This corrects the problem that the MAC output will vary depending upon the
TLS hash function. It clarifies that HMAC is used with the hash function
negotiated in TLS.   It also clarifies that the  EAP Type used in the TLS
message is the TEAP EAP type encoded as a single byte.   The use of the
TEAP type is to prevent cross protocol attacks in the case that the same
crypto-binding TLV structure is used in multiple EAP tunneling protocols.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] Proposed resolution for TEAP errata 5765

[Joseph Salowey]

On Fri, Oct 23, 2020 at 9:20 AM Jouni Malinen  wrote:

> On Thu, Oct 22, 2020 at 05:44:33PM +0300, Oleg Pekar wrote:
> > The Authority-ID TLV is used by the client to identify the TEAP server it
> > is talking to. If the same client talks to more than one TEAP server - it
> > can keep PACs or cached data from all of them identified by
> > the Authority-ID. If we make it optional in TEAP start message but keep
> > mandatory in PAC-Info part of the PAC - TEAP servers can stop sending it
> > during TEAP start and then clients will need to fetch it from PAC, if
> there
> > is a PAC in the conversation. But if there's no PAC - then no way to
> > identify TEAP server.
> >
> > Maybe we should keep it mandatory?
>
> That would be in conflict with Section 4.3.1: "Outer TLVs MUST be marked
> as optional."
>
> Please note that this M flag does not define whether the attribute must
> be included in the message; it defines whether the recipient has to
> reject the message if it does not support the TLV. We can still
> require the Authority-ID TLV to be present in TEAP/Start while marking
> it optional for the receiver to understand it (M=0).. And Section 3.2
> does indeed say that:
>The EAP server initiates the TEAP conversation with an EAP request
>containing a TEAP/Start packet.  This packet includes a set Start (S)
>bit, the TEAP version as specified in Section 3.1, and an authority
>identity TLV.
>
> This is still valid with M=0 for that TLV..
>
>
[Joe] I agree with Jouni here.  It is still valid to require the authority
ID in the message, the receiver does not have to process it.




> --
> Jouni MalinenPGP id EFC895FA
>
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] Consensus Call on OCSP usage in draft-ietf-emu-eap-tls13-11

[Joseph Salowey]

On Fri, Oct 30, 2020 at 4:44 AM Michael Richardson 
wrote:

>
> Joseph Salowey  wrote:
> >> I suggest:
> >>
> >> “EAP-TLS servers supporting TLS 1.3 that use OCSP to do certificate
> >> recovation checks,  MUST implement Certificate Status Requests
> using OCSP
> >> stapling as specified in Section 4.4.2.1 of [RFC8446].
>
> > [Joe] Thanks Michael,  I think your suggestion is a better way to
> phrase it
>
> Just so that we are clear:  this mandates OCSP+stapling for systems that do
> revocation checks.
>
> Systems that don't do revocation checks (current mbedtls), therefore don't
> need to do OCSP or stapling.
>

[Joe] That's not how I read your text.  I think your text mandates
OCSP+stapling for systems that use OCSP for revocation.

TLS 1.3 RFC 8446 does not mandate a particular revocation mechanism either,
as revocation is part of PKIX.

Also to be clear you text does not mandate that either servers or clients
support OCSP Stapling.

I think it would be appropriate to modify your text to replace "use" with
support.

"EAP-TLS servers supporting TLS 1.3 that support OCSP to do certificate
revocation checks,  MUST implement Certificate Status Requests using OCSP
stapling as specified in Section 4.4.2.1 of [RFC8446]."





> --
> Michael Richardson. o O ( IPv6 IøT consulting )
>Sandelman Software Works Inc, Ottawa and Worldwide
>
>
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

[Emu] Revised resolution for Erratum 5128

[Joseph Salowey]

I think this one is also done.  PR is here
https://github.com/emu-wg/teap-errata/pull/4.  Please comment on this
thread or PR if you think it still needs work:

Errata 5128: https://www.rfc-editor.org/errata/eid5128
Proposed State: Verified
Revision:

Section 5.2. says

 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]

where TLS-PRF is the PRF negotiated as part of TLS handshake [RFC5246].

It Should Say:

 S-IMCK[0] = session_key_seed
For j = 1 to n-1 do
   IMCK[j] = the first 60 octets of TLS-PRF(S-IMCK[j-1],
  "Inner Methods Compound Keys", IMSK[j])
   S-IMCK[j] = first 40 octets of IMCK[j]
   CMK[j] = last 20 octets of IMCK[j]

where "|" denotes concatenation and the TLS-PRF is defined in
[RFC5246] as

PRF(secret, label, seed) = P_(secret, label | seed).

the secret is S-IMCK[j-1],  the label is
"Inner Methods Compound Keys" consisting of the ASCII value for the
label "Inner Methods Compound Keys" (without quotes),  the seed
consists IMSK[j].

Section 5.4 Says:

  MSK  = TLS-PRF(S-IMCK[j], "Session Key Generating Function", 64)
  EMSK = TLS-PRF(S-IMCK[j],
   "Extended Session Key Generating Function", 64)

  where j is the number of the last successfully executed inner EAP method.

It should say:

  MSK = the first 64 octets of TLS-PRF(S-IMCK[j],
   "Session Key Generating Function")
  EMSK = the first 64 octets of TLS-PRF(S-IMCK[j],
   "Extended Session Key Generating Function")

  where "|" denotes concatenation and the TLS-PRF is defined in
  [RFC5246] as

PRF(secret, label, seed) = P_(secret, label | seed).

 The secret is S-IMCK[j]  where j is the number of the last generated
 S-IMCK from section 5.2.  The label is is the ASCII value for the
 string without quotes.  The seed is empty (0 length) and omitted from
 the derivation.

Notes:

According to

RFC5246 The Transport Layer Security (TLS) Protocol Version 1.2

5. HMAC and the Pseudorandom Function

"TLS's PRF is created by applying P_hash to the secret as:

PRF(secret, label, seed) = P_(secret, label + seed)"
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] Consensus Call on OCSP usage in draft-ietf-emu-eap-tls13-11

[Joseph Salowey]

On Thu, Oct 29, 2020 at 3:12 PM Michael Richardson 
wrote:

>
> Joseph Salowey  wrote:
> > 2. Require Servers to Implement and Recommended to Use OCSP with text
> > similar to the following:
>
> I don't think that this text is quite right.
>
> I note that "RECOMMENDED" is a synonym for SHOULD, and usually we ask
> documents to explain what a reasonable exception might look like.
> This text does not do that.
>
> > “EAP-TLS servers supporting TLS 1.3 MUST implement Certificate Status
> > Requests (OCSP stapling) as specified in Section 4.4.2.1 of
> [RFC8446].  It
> > is RECOMMENDED that EAP-TLS peers and servers use OCSP stapling for
> > verifying the status of server certificates as specified in Section
> 4.4.2.1
> > of [RFC8446]. When an EAP-TLS peer uses OCSP to verify the
> certificate
> > status of the EAP-TLS server, it MUST use Certificate Status
> Requests for
> > the server's certificate chain and it MUST treat a CertificateEntry
> (except
> > the trust anchor) without a valid CertificateStatus extension as
> invalid
> > and abort the handshake with an appropriate alert.“
>
> I suggest:
>
> “EAP-TLS servers supporting TLS 1.3 that use OCSP to do certificate
> recovation checks,  MUST implement Certificate Status Requests using OCSP
> stapling as specified in Section 4.4.2.1 of [RFC8446].
>
> It is RECOMMENDED that EAP-TLS peers and servers use OCSP (with stapling)
> for
> verifying the status of server certificates as specified in Section 4.4.2.1
> of [RFC8446].
>  mandated for TLS. I can't find the right place>
>
> When an EAP-TLS peer uses OCSP to verify the certificate status of the
> EAP-TLS server, it MUST use Certificate Status Requests for the server's
> certificate chain and it MUST treat a CertificateEntry (except the trust
> anchor) without a valid CertificateStatus extension as invalid and abort
> the
> handshake with an appropriate alert.“
>
> I don't know much about the last part.
> I suggest it be split as three paragraphs for readability.
>
>
[Joe] Thanks Michael,  I think your suggestion is a better way to phrase it


> --
> Michael Richardson. o O ( IPv6 IøT consulting )
>Sandelman Software Works Inc, Ottawa and Worldwide
>
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] Consensus Call on OCSP usage in draft-ietf-emu-eap-tls13-11

[Joseph Salowey]

On Thu, Oct 29, 2020 at 10:30 AM Max Pala  wrote:

> Hi Eliot, all,
>
>
>
> In our industry we solved this issue by *requiring OCSP stapling if and
> only if the certificate being validated carries the OCSP URI in the
> certificate*.
>
>
>
> This allows us to live in a mixed environment where support for OCSP might
> have been introduced later on and allows the CA to explicitly support OCSP
> for the certificate by including the URL in it.
>
>
>
> If the “ecosystem” policy allows it – you might suggest that if OCSP
> responses are not not provided but the URL where to get OCSP responses is
> known to the device (or it is in the certificate), the device/entity can
> continue with the authentication but it should not enable any device/entity
> functionality before successfully executing (and validating) the OCSP
> protocol first (and disconnect if not reachable/invalid/revoked).
>
>
>

[Joe] So you are in favor of both clients and servers
mandatory implementing OCSP, but only requiring it be used when it is
signalled in the certificate?


> Just my 2 cents.
>
>
>
> Cheers,
> Max
>
>
>
> *From: *Emu  on behalf of Eliot Lear  40cisco@dmarc.ietf.org>
> *Date: *Thursday, October 29, 2020 at 10:53 AM
> *To: *Joseph Salowey 
> *Cc: *EMU WG 
> *Subject: *Re: [Emu] Consensus Call on OCSP usage in
> draft-ietf-emu-eap-tls13-11
>
>
>
> Hi Joe,
>
>
>
> My suggestion is that we add some discussion about what to do in the case
> of no connectivity to the CA.  This will be a not-uncommon occurrence,
> IMHO, in industrial use cases.
>
>
>
> Eliot
>
>
>
> On 29 Oct 2020, at 17:23, Joseph Salowey  wrote:
>
>
>
> An issue was raised in a review of  draft-ietf-emu-eap-tls13-11 on the
> mandatory requirement for OCSP stapling [1].  The document makes the use of
> OCSP mandatory in section 5.4 [2]. Several folks have pointed out that this
> may not be feasible in all deployments.  This is a quick consensus call for
> this issue.   Please indicate which option below you support and why.
> Please respond by November 5, 2020.
>
> 1. Keep the text as is with OCSP mandatory for all implementations
>
> 2. Require Servers to Implement and Recommended to Use OCSP with text
> similar to the following:
>
> “EAP-TLS servers supporting TLS 1.3 MUST implement Certificate Status
> Requests (OCSP stapling) as specified in Section 4.4.2.1 of [RFC8446].  It
> is RECOMMENDED that EAP-TLS peers and servers use OCSP stapling for
> verifying the status of server certificates as specified in Section 4.4.2.1
> of [RFC8446]. When an EAP-TLS peer uses OCSP to verify the certificate
> status of the EAP-TLS server, it MUST use Certificate Status Requests for
> the server's certificate chain and it MUST treat a CertificateEntry (except
> the trust anchor) without a valid CertificateStatus extension as invalid
> and abort the handshake with an appropriate alert.“
>
>
>
> Thanks,
>
>
>
> Joe
>
>
>
> [1] https://mailarchive.ietf.org/arch/msg/emu/0DnfUWPqvKX0_Wo8s-ZypergMHI/
> [2] https://tools.ietf.org/html/draft-ietf-emu-eap-tls13-11#section-5.4
>
> ___
> Emu mailing list
> Emu@ietf.org
> https://www.ietf.org/mailman/listinfo/emu
>
>
>
> ___ Emu mailing list
> Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
>
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

[Emu] Consensus Call on OCSP usage in draft-ietf-emu-eap-tls13-11

[Joseph Salowey]

An issue was raised in a review of  draft-ietf-emu-eap-tls13-11 on the
mandatory requirement for OCSP stapling [1].  The document makes the use of
OCSP mandatory in section 5.4 [2]. Several folks have pointed out that this
may not be feasible in all deployments.  This is a quick consensus call for
this issue.   Please indicate which option below you support and why.
Please respond by November 5, 2020.

1. Keep the text as is with OCSP mandatory for all implementations

2. Require Servers to Implement and Recommended to Use OCSP with text
similar to the following:

“EAP-TLS servers supporting TLS 1.3 MUST implement Certificate Status
Requests (OCSP stapling) as specified in Section 4.4.2.1 of [RFC8446].  It
is RECOMMENDED that EAP-TLS peers and servers use OCSP stapling for
verifying the status of server certificates as specified in Section 4.4.2.1
of [RFC8446]. When an EAP-TLS peer uses OCSP to verify the certificate
status of the EAP-TLS server, it MUST use Certificate Status Requests for
the server's certificate chain and it MUST treat a CertificateEntry (except
the trust anchor) without a valid CertificateStatus extension as invalid
and abort the handshake with an appropriate alert.“

Thanks,

Joe

[1] https://mailarchive.ietf.org/arch/msg/emu/0DnfUWPqvKX0_Wo8s-ZypergMHI/
[2] https://tools.ietf.org/html/draft-ietf-emu-eap-tls13-11#section-5.4
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] Proposed Resolution to TEAP Errata 5770

[Joseph Salowey]

On Tue, Oct 27, 2020 at 12:23 AM Eliot Lear  wrote:

> Hi,
>
> >
> > [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.
> >
>
> Keep in mind that there might not even be basic auth.  One case is that
> one just uses the OUTER auth, does some PKCS ops or extensions and then
> wants to conclude.  No inner in this case.  Which erratum is that covered
> by?
>
>
[Joe]  Erratum 5775 discusses how to generate key material when there is
no inner authentication method such as the case you describe.


> Eliot
>
>
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] draft-ietf-emu-eap-tls13-11: OCSP Stapling

[Joseph Salowey]

On Tue, Oct 27, 2020 at 11:27 AM Hannes Tschofenig <
hannes.tschofe...@arm.com> wrote:

> Hi Joe,
>
>
>
> a few remarks below.
>
>
>
>
>
> On Fri, Oct 23, 2020 at 12:38 AM Hannes Tschofenig <
> hannes.tschofe...@arm.com> wrote:
>
> Hi Joe,
>
>
>
> I do not understand certificate revocation checking is a topic specific to
> the use of TLS 1.3 in EAP-TLS.
>
>
>
> [Joe]  TLS 1.3 discusses OCSP and (SCT).  OCSP stapling is a revocation
> mechanism that will work when the EAP-TLS client does not have connectivity
> yet, which is a common case in EAP-TLS deployments.The way the draft is
> written now it mandates that this mechanism be used and implements.  TLS
> 1.3 does not require this.
>
>
>
> [hannes] It is also common to give network access to devices that need a
> software update or configuration changes.
>
>
>
> What do you expect to happen if the device finds out that the certificate
> offered by the server has expired?
>
>
>
[Joe] If the server is offering an expired or revoked certificate then that
needs to be remedied on the server.


>
>
> If this topic is important to the group then why isn’t this a generic
> recommendations for all EAP methods that use public key based
> authentication?
>
>
>
>
>
> [Joe] Certificate revocation is specific to the use of certificates.
>
>
>
> [Hannes] Many EAP methods use certificates but they do not mandate the use
> of OCSP.
>
>
>
> Wouldn’t this be a topic to address in ? IMHO
> this would make more sense given that  talks
> about large certificates and long certificate chains and any proposal to
> make those even larger should be evaluated in this context.
>
>
>
>
>
> [Joe] No,  discusses handling large
> certificates not revocation.
>
>
>
> [Hannes] Here the problem description that motivates
> 
>
> “
>
> Large certificates and long
>
>certificate chains combined with authenticators that drop an EAP
>
>session after only 40 - 50 round-trips is a major deployment problem.
>
>This document looks at the this problem in detail and describes the
>
>potential solutions available.
>
> “
>
> OCSP information travels alongside the certificates and therefore
> increases the problem outlined by 
>
>
>
> EAP-TLS is the right place to discuss revocation issues.
>
>
>
> It seems there are several questions that need to be answered:
>
>
>
>1. Should the document mandate that OCSP stapling be used?
>
> [Hannes] No.
>
>
>
> 2. Should the document mandate that OCSP stapling be implemented?
>
> [Hannes] No.
>
>
>
> 3. What should the document say in the security sections with respect to
> OCSP stapling and other mechanisms?
>
> [Hannes] IMHO TLS 1.3 says the relevant solution parts. OCSP stapling is
> available for use in TLS 1.3 and it is one suitable mechanism for
> certificate revocation.
>
>
>
> Do any of these recommendations also apply to EAP-TLS with TLS 1.2 as well
> (since it also offers OCSP stapling)? Would the recommendations also apply
> to EAP methods that use TLS under the hood, such as TEAP, EAP-FAST, or
> EAP-TTLS? Would they apply to methods like EAP-IKEv2 or the recently
> suggested EAP-EDHOC, which are also methods that use certificates?
>

[Joe] the document under consideration is EAP-TLS 1.3.   In my opinion any
document that deals with certificates ought to have some discussion on
revocation.  In particular, EAP is deployed into an environment where some
revocation mechanisms may not work as expected because there is no network
access available to do out of band checks.


>
>
> Ciao
>
> Hannes
>
>
>
> Ciao
>
> Hannes
>
>
>
> *From:* Joseph Salowey 
> *Sent:* Thursday, October 22, 2020 11:12 PM
> *To:* Eliot Lear 
> *Cc:* Hannes Tschofenig ; emu@ietf.org
> *Subject:* Re: [Emu] draft-ietf-emu-eap-tls13-11: OCSP Stapling
>
>
>
>
>
>
>
> On Thu, Oct 22, 2020 at 8:08 AM Eliot Lear  40cisco@dmarc.ietf.org> wrote:
>
> +1.  How does anyone even do OCSP without having first gotten onto the
> network?
>
>
>
>
>
> [Joe] THat is what OCSP stapling is supposed to solve since the OCSP
> messages are sent in the TLS handshake.   I believe there are some EAP-TLS
> implementations that support OCSP, but I am not sure if it is actually
> deployed.
>
>
>
> Eliot
>
>
>
> On 21 Oct 2020, at 11:02, Hannes Tschofenig 
> wrote:
>
>
>
> Hi all,
>
>
>
> this draft mandates OCSCP stapling (for use with TLS 1.3 in EAP-TLS) and I
> believe this is a problem for implementations. This extra bu

Re: [Emu] draft-ietf-emu-eap-tls13-11: OCSP Stapling

[Joseph Salowey]

On Fri, Oct 23, 2020 at 12:38 AM Hannes Tschofenig <
hannes.tschofe...@arm.com> wrote:

> Hi Joe,
>
>
>
> I do not understand certificate revocation checking is a topic specific to
> the use of TLS 1.3 in EAP-TLS.
>
>
>

[Joe]  TLS 1.3 discusses OCSP and (SCT).  OCSP stapling is a revocation
mechanism that will work when the EAP-TLS client does not have connectivity
yet, which is a common case in EAP-TLS deployments.The way the draft is
written now it mandates that this mechanism be used and implements.  TLS
1.3 does not require this.


> If this topic is important to the group then why isn’t this a generic
> recommendations for all EAP methods that use public key based
> authentication?
>
>
>

[Joe] Certificate revocation is specific to the use of certificates.


> Wouldn’t this be a topic to address in ? IMHO
> this would make more sense given that  talks
> about large certificates and long certificate chains and any proposal to
> make those even larger should be evaluated in this context.
>
>
>

[Joe] No,  discusses handling large certificates
not revocation.  EAP-TLS is the right place to discuss revocation issues.
It seems there are several questions that need to be answered:

1. Should the document mandate that OCSP stapling be used?
2. Should the document mandate that OCSP stapling be implemented?
3. What should the document say in the security sections with respect to
OCSP stapling and other mechanisms?







> Ciao
>
> Hannes
>
>
>
> *From:* Joseph Salowey 
> *Sent:* Thursday, October 22, 2020 11:12 PM
> *To:* Eliot Lear 
> *Cc:* Hannes Tschofenig ; emu@ietf.org
> *Subject:* Re: [Emu] draft-ietf-emu-eap-tls13-11: OCSP Stapling
>
>
>
>
>
>
>
> On Thu, Oct 22, 2020 at 8:08 AM Eliot Lear  40cisco@dmarc.ietf.org> wrote:
>
> +1.  How does anyone even do OCSP without having first gotten onto the
> network?
>
>
>
>
>
> [Joe] THat is what OCSP stapling is supposed to solve since the OCSP
> messages are sent in the TLS handshake.   I believe there are some EAP-TLS
> implementations that support OCSP, but I am not sure if it is actually
> deployed.
>
>
>
> Eliot
>
>
>
> On 21 Oct 2020, at 11:02, Hannes Tschofenig 
> wrote:
>
>
>
> Hi all,
>
>
>
> this draft mandates OCSCP stapling (for use with TLS 1.3 in EAP-TLS) and I
> believe this is a problem for implementations. This extra burden is IMHO
> unjustified. For the type of deployments where EAP is used there is no need
> for a mandatory certificate revocation checking with OCSP.
>
>
>
> Having it optional, like the use of many other TLS extensions, is fine for
> me. FWIW even TLS 1.3, which is used in a more generic environment, does
> not mandate the use of OCSP stapling.
>
>
>
> This requirement will make the problem described in
> draft-ietf-emu-eaptlscert worse. I am sure the authors are aware of this
> fact since they are also co-authors of draft-ietf-emu-eaptlscert.
>
>
>
> Ciao
>
> Hannes
>
> IMPORTANT NOTICE: The contents of this email and any attachments are
> confidential and may also be privileged. If you are not the intended
> recipient, please notify the sender immediately and do not disclose the
> contents to any other person, use it for any purpose, or store or copy the
> information in any medium. Thank you.
> ___
> Emu mailing list
> Emu@ietf.org
> https://www.ietf.org/mailman/listinfo/emu
>
>
>
> ___
> Emu mailing list
> Emu@ietf.org
> https://www.ietf.org/mailman/listinfo/emu
>
> IMPORTANT NOTICE: The contents of this email and any attachments are
> confidential and may also be privileged. If you are not the intended
> recipient, please notify the sender immediately and do not disclose the
> contents to any other person, use it for any purpose, or store or copy the
> information in any medium. Thank you.
>
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] Proposed Resolution to TEAP Errata 5770

[Joseph Salowey]

On Mon, Oct 26, 2020 at 12:51 PM Jorge Vergara 
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 
> *Sent:* Saturday, October 24, 2020 5:18 PM
> *To:* EMU WG 
> *Cc:* Oleg Pekar ; Jouni Malinen ;
> Jorge Vergara 
> *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=04%7C01%7Cjovergar%40microsoft.com%7C728ceb6af6694e40e08e08d8787b669d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637391818689781723%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000=RuRrXZ5c70r43Rmyl4s%2BVUKAA22nGtoenLElbCeUkmE%3D=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
>
>  b

Re: [Emu] Proposed Resolution to TEAP Errata 5844

[Joseph Salowey]

On Mon, Oct 26, 2020 at 1:27 AM Oleg Pekar 
wrote:

> Few comments:
> 1) It seems that the server MUST send Crypto-Binding TLV after a single
> EAP authentication method, after each of EAP authentications methods in a
> sequence, after no inner method but not after
> Basic-Password-Authentication. Shouldn't we close this gap for the sake of
> simplicity and structure? (Only Zero-MSK Crypto-Binding TLV is possible in
> this case, the same as in no inner method case). Is
> Basic-Password-Authentication treated as a case of no inner method?
> Technically it is already correct but still may not be clear enough.
>
> This also affects section "4.2.13. Crypto-Binding TLV":
>
> 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.
>
> Shouldn't we mention "inner EAP method or basic password authentication"?
>

[Joe] There are two cases where CryptoBinding is used, after completion of
an EAP authentication exchange and with the Result-TLV exchange.   Since
password based authentication does not generate a key there is no need for
crypto binding.  It is just treated as a TLV.


>
> 2) [Minor] It is written both "EAP methods **and** basic password
> authentication" and "EAP methods **or**basic password authentication" in
> different sections above. Shouldn't we use the same all the time?
>
> [Joe] It should be consistent. Re-worded slightly:

3. The Intermediate-Result TLVs carry success or failure indications of
each individual EAP authentication method or basic password authentication
in TEAP Phase 2.

And

The Intermediate-Result TLV provides support for acknowledged intermediate
Success and Failure messages for inner EAP authentication methods or basic
password authentication.


>
> On Sun, Oct 25, 2020 at 9:10 PM Joseph Salowey  wrote:
>
>> Errata 5844: https://www.rfc-editor.org/errata/eid5844
>> Status: Verified
>> Revision:
>>
>> Section 3.3.2 says:
>>
>> Upon receiving the response, the server
>>indicates the success or failure of the exchange using an
>>Intermediate-Result TLV.
>>
>> It Should say:
>>
>> Upon receiving the response, the server MUST
>>indicate the success or failure of the exchange using an
>>Intermediate-Result TLV.
>>
>> Section 3.6 says:
>>
>> 3. The Intermediate-Result TLVs carry success or failure indications of
>> the individual EAP methods in TEAP Phase 2.
>>
>> It Should say:
>>
>> 3. The Intermediate-Result TLVs carry success or failure indications of
>> the individual EAP methods and basic password authentication in TEAP Phase
>> 2.
>>
>> Section 4.2.11 says:
>>
>> The Intermediate-Result TLV provides support for acknowledged
>> intermediate Success and Failure messages between multiple inner EAP
>> methods within EAP.
>>
>> It Should say:
>>
>> The Intermediate-Result TLV provides support for acknowledged
>> intermediate Success and Failure messages between multiple inner EAP
>> methods or basic password authentication within EAP.
>>
>> Section C.1 says:
>>
>> <- Crypto-Binding TLV (Request),
>> Result TLV (Success),
>> (Optional PAC TLV)
>>
>>Crypto-Binding TLV(Response),
>>Result TLV (Success),
>>(PAC-Acknowledgement TLV) ->
>>
>> It should say:
>>
>> <- Intermediate-Result-TLV (Success),
>> Crypto-Binding TLV (Request),
>> Result TLV (Success),
>> (Optional PAC TLV)
>>
>>Intermediate-Result-TLV (Success),
>>Crypto-Binding TLV(Response),
>>Result TLV (Success),
>>(PAC-Acknowledgement TLV) ->
>>
>> Section C.2 Says:
>> <- Result TLV (Failure)
>>
>> Result TLV (Failure) ->
>>
>> It Should Say:
>>
>> <- Intermediate-Result-TLV (Failure),
>>  Result TLV (Failure)
>>
>> Intermediate-Result-TLV (Failure),
>>Result TLV (Failure) ->
>>
>>
>> Notes:
>>
>> Section 3.3.2 implies that Intermediate-Result TLV is used after each
>> round of Basic-Password-Auth-Req/Resp TLVs. However, the example sequence
>> in C.1 does not show this. The proposed change in this errata adds the
>> Intermediate

Re: [Emu] Proposed Resolution for Errata 5845

[Joseph Salowey]

On Mon, Oct 26, 2020 at 1:27 AM Oleg Pekar 
wrote:

> >It should say:
> >
> >   EAP method messages are carried within EAP-Payload TLVs defined in
> >   Section 4.2.10.  Upon method completion, the server MUST send an
> >  Intermediate-Result TLV indicating the result.
>
> Jouni explained in errata 5767 that not all EAP methods are EAP
> authentication methods, to be exact. In the proposed fix for errata 5767
> you have already suggested that for Section 3.3.1 text:
>
> >Section 3.3.1
> >
> >It should say:
>
> >   EAP method messages are carried within EAP-Payload TLVs defined in
> >   Section 4.2.10.  Upon completion of each EAP authentication method in
> >   the tunnel, the server MUST send an Intermediate-Result TLV
> >   indicating the result.
>
>
[Joe] Yes, I think you are correct.


>
>
> On Sun, Oct 25, 2020 at 9:14 PM Joseph Salowey  wrote:
>
>> Errata 5845: https://www.rfc-editor.org/errata/eid5845
>> Proposed Status: Verified
>> Revision:
>>
>> Section 3.3.1 says:
>>
>>EAP method messages are carried within EAP-Payload TLVs defined in
>>Section 4.2.10.  If more than one method is going to be executed in
>>the tunnel, then upon method completion, the server MUST send an
>>Intermediate-Result TLV indicating the result.
>>
>> It should say:
>>
>>EAP method messages are carried within EAP-Payload TLVs defined in
>>Section 4.2.10.  Upon method completion, the server MUST send an
>>Intermediate-Result TLV indicating the result.
>>
>> Notes:
>>
>> Description of whether Intermediate-Result TLV is supposed to be used in
>> the case where only a single inner EAP authentication method is used.
>> Section 3.3.1 says "more than one method is going to be executed in the
>> tunnel, then upon method completion, the server MUST send an
>> Intermediate-Result TLV indicating the result", Section 3.3.3 says "The
>> Crypto-Binding TLV and Intermediate-Result TLV MUST be included to perform
>> cryptographic binding after each successful EAP method in a sequence of one
>> or more EAP methods", 4.2.13 says "It MUST be included with the
>> Intermediate-Result TLV to perform cryptographic binding after each
>> successful EAP method in a sequence of EAP methods", Annex C.3 shows an
>> example exchange with a single inner EAP authentication method with use of
>> Intermediate-Result TLV.
>>
>> It looks like the majority of the places discussion this topic implies
>> that there is going to be an Intermediate-Result TLV after each inner EAP
>> authentication method and the text in 3.3.1 is the only clear case of
>> conflicting (or well, at least misleading if one were to claim it does not
>> explicitly say MUST NOT for the one inner EAP authentication method case).
>> As such, I'd conclude the Intermediate-Result TLV is indeed going to be
>> exchanged after each EAP authentication method and the proposed text change
>> to 3.3.1 covers that.
>>
>
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] Proposed resolution for TEAP errata 5775

[Joseph Salowey]

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

[Emu] Proposed Resolution for TEAP Errata 6157

[Joseph Salowey]

Errata 6157: https://www.rfc-editor.org/errata/eid6157
Proposed Status: Verified
Revision:
Section 4.2.9 says:

  Status

  The Status field is one octet.  This indicates the result if the
  server does not process the action requested by the peer.

It should say:

  Status

  The Status field is one octet.  This indicates the result if the
  party who receives this TLV does not process the action.

Notes:

The status field is carried in the "Request-Action" frame. As is repeatedly
stated in the chapeau of the section, the frame can be sent either by the
server or the peer.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

[Emu] Proposed Resolution for Errata 5845

[Joseph Salowey]

Errata 5845: https://www.rfc-editor.org/errata/eid5845
Proposed Status: Verified
Revision:

Section 3.3.1 says:

   EAP method messages are carried within EAP-Payload TLVs defined in
   Section 4.2.10.  If more than one method is going to be executed in
   the tunnel, then upon method completion, the server MUST send an
   Intermediate-Result TLV indicating the result.

It should say:

   EAP method messages are carried within EAP-Payload TLVs defined in
   Section 4.2.10.  Upon method completion, the server MUST send an
   Intermediate-Result TLV indicating the result.

Notes:

Description of whether Intermediate-Result TLV is supposed to be used in
the case where only a single inner EAP authentication method is used.
Section 3.3.1 says "more than one method is going to be executed in the
tunnel, then upon method completion, the server MUST send an
Intermediate-Result TLV indicating the result", Section 3.3.3 says "The
Crypto-Binding TLV and Intermediate-Result TLV MUST be included to perform
cryptographic binding after each successful EAP method in a sequence of one
or more EAP methods", 4.2.13 says "It MUST be included with the
Intermediate-Result TLV to perform cryptographic binding after each
successful EAP method in a sequence of EAP methods", Annex C.3 shows an
example exchange with a single inner EAP authentication method with use of
Intermediate-Result TLV.

It looks like the majority of the places discussion this topic implies that
there is going to be an Intermediate-Result TLV after each inner EAP
authentication method and the text in 3.3.1 is the only clear case of
conflicting (or well, at least misleading if one were to claim it does not
explicitly say MUST NOT for the one inner EAP authentication method case).
As such, I'd conclude the Intermediate-Result TLV is indeed going to be
exchanged after each EAP authentication method and the proposed text change
to 3.3.1 covers that.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

[Emu] Proposed Resolution to TEAP Errata 5844

[Joseph Salowey]

Errata 5844: https://www.rfc-editor.org/errata/eid5844
Status: Verified
Revision:

Section 3.3.2 says:

Upon receiving the response, the server
   indicates the success or failure of the exchange using an
   Intermediate-Result TLV.

It Should say:

Upon receiving the response, the server MUST
   indicate the success or failure of the exchange using an
   Intermediate-Result TLV.

Section 3.6 says:

3. The Intermediate-Result TLVs carry success or failure indications of the
individual EAP methods in TEAP Phase 2.

It Should say:

3. The Intermediate-Result TLVs carry success or failure indications of the
individual EAP methods and basic password authentication in TEAP Phase 2.

Section 4.2.11 says:

The Intermediate-Result TLV provides support for acknowledged intermediate
Success and Failure messages between multiple inner EAP methods within EAP.

It Should say:

The Intermediate-Result TLV provides support for acknowledged intermediate
Success and Failure messages between multiple inner EAP methods or basic
password authentication within EAP.

Section C.1 says:

<- Crypto-Binding TLV (Request),
Result TLV (Success),
(Optional PAC TLV)

   Crypto-Binding TLV(Response),
   Result TLV (Success),
   (PAC-Acknowledgement TLV) ->

It should say:

<- Intermediate-Result-TLV (Success),
Crypto-Binding TLV (Request),
Result TLV (Success),
(Optional PAC TLV)

   Intermediate-Result-TLV (Success),
   Crypto-Binding TLV(Response),
   Result TLV (Success),
   (PAC-Acknowledgement TLV) ->

Section C.2 Says:
<- Result TLV (Failure)

Result TLV (Failure) ->

It Should Say:

<- Intermediate-Result-TLV (Failure),
 Result TLV (Failure)

Intermediate-Result-TLV (Failure),
   Result TLV (Failure) ->


Notes:

Section 3.3.2 implies that Intermediate-Result TLV is used after each round
of Basic-Password-Auth-Req/Resp TLVs. However, the example sequence in C.1
does not show this. The proposed change in this errata adds the
Intermediate-Result TLV indication here. Similar change should be done in
C.2 (i.e., add Intermediate-Result TLV (Failure) to the messages that
include Result TLV) since the language in 3.3.2 describe the indication to
be used for both success and failure cases.

In addition to this change in C.1, it would be good to clarify the
specification globally to avoid confusion about this case since almost all
discussion regarding Intermediate-Result TLV currently is in the context of
inner EAP authentication. 3.3.2 should have a MUST statement similar to
3.3.1. 3.6 should cover success or failure indications of basic password
auth like it does EAP methods. 4.2.11 should note Intermediate-Result TLV
is used with both inner EAP and basic password auth.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

[Emu] Proposed resolution for TEAP errata 5775

[Joseph Salowey]

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

Re: [Emu] Proposed Resolution for TEAP errata 5768

[Joseph Salowey]

On Sat, Oct 24, 2020 at 4:29 PM Oleg Pekar 
wrote:

> > 2  The EAP Type sent by the other party in the first TEAP message. This
> is a single octet encoded as (0x37)
>
> Shouldn't we clarify the motivation for placing the octet with TEAP type
> 0x37 into the BUFFER? Joe, I remember you explained that it is for
> protection against cross protocol attacks if Crypto-Binding TLV was reused
> (e.g. from PEAP).
>

[Joe]  That's more of an editorial comment that we would hold for a
document revision.  I think we should try to keep the revision text at a
minimum, but we certainly can include this information in the errata
notes.


> On Sun, Oct 25, 2020 at 12:45 AM Joseph Salowey  wrote:
>
>> Errata 5768:  https://www.rfc-editor.org/errata/eid5768
>> Proposed State: Verified
>> Revision:
>>
>> Section 4.2.13. Says:
>>
>> Length
>>
>> 76
>>
>> It should say:
>>
>> Length
>>
>>  36 plus the length of the 2 MAC fields
>>
>> Section 4.2.13. Says:
>>
>>EMSK Compound MAC
>>
>>   The EMSK Compound MAC field is 20 octets.  This can be the Server
>>   MAC (B1_MAC) or the Client MAC (B2_MAC).  The computation of the
>>   MAC is described in Section 5.3.
>>
>>MSK Compound MAC
>>
>>   The MSK Compound MAC field is 20 octets.  This can be the Server
>>   MAC (B1_MAC) or the Client MAC (B2_MAC).  The computation of the
>>   MAC is described in Section 5.3.
>>
>> It Should Say:
>>
>>EMSK Compound MAC
>>
>>   The computation of the MAC is described in Section 5.3.  This can
>> be
>>   the Server MAC (B1_MAC) or the Client MAC (B2_MAC).
>>
>>MSK Compound MAC
>>
>>   The computation of the MAC is described in Section 5.3.  This can
>> be
>>   the Server MAC (B1_MAC) or the Client MAC (B2_MAC).
>>
>> Section 5.3 Says:
>>
>>  The Compound MAC computation is as follows:
>>
>>   CMK = CMK[j]
>>   Compound-MAC = MAC( CMK, BUFFER )
>>
>>where j is the number of the last successfully executed inner EAP
>>method, MAC is the MAC function negotiated in TLS 1.2 [RFC5246], and
>>BUFFER is created after concatenating these fields in the following
>>order:
>>
>>1  The entire Crypto-Binding TLV attribute with both the EMSK and MSK
>>   Compound MAC fields zeroed out.
>>
>>2  The EAP Type sent by the other party in the first TEAP message.
>>
>> It Should say:
>>
>>  The Compound MAC computation is as follows:
>>
>>   CMK = CMK[j]
>>   Compound-MAC = MAC( CMK, BUFFER )
>>
>>where j is the number of the last successfully executed inner EAP
>>method, MAC is HMAC [RFC2104] using the hash function negotiated in
>>TLS [RFC5246].  The output length is the length of the output of the
>> HMAC
>>function.  The BUFFER is created after concatenating these fields in
>>the following order:
>>
>>1  The entire Crypto-Binding TLV attribute with both the EMSK and MSK
>>   Compound MAC fields zeroed out.
>>
>>2  The EAP Type sent by the other party in the first TEAP message. This
>>is a single octet encoded as (0x37)
>>
>> Notes:
>>
>> This corrects the problem that the MAC output will vary depending upon
>> the TLS hash function. It clarifies that HMAC is used with the hash
>> function negotiated in TLS.   It also clarifies that the  EAP Type used in
>> the TLS message is the TEAP EAP type encoded as a single byte.
>>
>
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

[Emu] Proposed Resolution to TEAP Errata 5770

[Joseph Salowey]

Errata 5770: https://www.rfc-editor.org/errata/eid5770
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 

[Emu] Proposed Resolution for TEAP errata 5768

[Joseph Salowey]

Errata 5768:  https://www.rfc-editor.org/errata/eid5768
Proposed State: Verified
Revision:

Section 4.2.13. Says:

Length

76

It should say:

Length

 36 plus the length of the 2 MAC fields

Section 4.2.13. Says:

   EMSK Compound MAC

  The EMSK Compound MAC field is 20 octets.  This can be the Server
  MAC (B1_MAC) or the Client MAC (B2_MAC).  The computation of the
  MAC is described in Section 5.3.

   MSK Compound MAC

  The MSK Compound MAC field is 20 octets.  This can be the Server
  MAC (B1_MAC) or the Client MAC (B2_MAC).  The computation of the
  MAC is described in Section 5.3.

It Should Say:

   EMSK Compound MAC

  The computation of the MAC is described in Section 5.3.  This can be
  the Server MAC (B1_MAC) or the Client MAC (B2_MAC).

   MSK Compound MAC

  The computation of the MAC is described in Section 5.3.  This can be
  the Server MAC (B1_MAC) or the Client MAC (B2_MAC).

Section 5.3 Says:

 The Compound MAC computation is as follows:

  CMK = CMK[j]
  Compound-MAC = MAC( CMK, BUFFER )

   where j is the number of the last successfully executed inner EAP
   method, MAC is the MAC function negotiated in TLS 1.2 [RFC5246], and
   BUFFER is created after concatenating these fields in the following
   order:

   1  The entire Crypto-Binding TLV attribute with both the EMSK and MSK
  Compound MAC fields zeroed out.

   2  The EAP Type sent by the other party in the first TEAP message.

It Should say:

 The Compound MAC computation is as follows:

  CMK = CMK[j]
  Compound-MAC = MAC( CMK, BUFFER )

   where j is the number of the last successfully executed inner EAP
   method, MAC is HMAC [RFC2104] using the hash function negotiated in
   TLS [RFC5246].  The output length is the length of the output of the HMAC
   function.  The BUFFER is created after concatenating these fields in
   the following order:

   1  The entire Crypto-Binding TLV attribute with both the EMSK and MSK
  Compound MAC fields zeroed out.

   2  The EAP Type sent by the other party in the first TEAP message. This
   is a single octet encoded as (0x37)

Notes:

This corrects the problem that the MAC output will vary depending upon the
TLS hash function. It clarifies that HMAC is used with the hash function
negotiated in TLS.   It also clarifies that the  EAP Type used in the TLS
message is the TEAP EAP type encoded as a single byte.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] Proposed resolution for TEAP errata for 5128

[Joseph Salowey]

I think we have agreement on what the derivation would be now it's a matter
of clearly describing it. Here is a proposal:
IMCK[j] = the first 60 bytes of TLS-PRF(S-IMCK[j-1], "Inner Methods
Compound Keys", IMSK[j])

  where "|" denotes concatenation and the TLS-PRF is defined in
  [RFC5246] as

PRF(secret, label, seed) = P_(secret, label | seed).

 the secret is S-IMCK[j-1],  the label is
 "Inner Methods Compound Keys" consisting of the ASCII value for the
 label "Inner Methods Compound Keys" (without quotes),  the seed
 consists IMSK[j].

MSK = the first 64 bytes of TLS-PRF(S-IMCK[j], "Session Key Generating
Function")
EMSK = the first 64 bytes of TLS-PRF(S-IMCK[j], "Extended Session Key
Generating Function")

  where "|" denotes concatenation and the TLS-PRF is defined in
  [RFC5246] as

PRF(secret, label, seed) = P_(secret, label | seed).

 The secret is S-IMCK[j-1]  where j is the number of the last
successfully
 executed inner EAP method.  The label is is the ASCII value for the
 string without quotes.  The seed is empty (0 length) and omitted from
 the derivation.

On Fri, Oct 23, 2020 at 9:58 AM Jouni Malinen  wrote:

> There were so many messages in this thread that I'm not going try to
> address each point separately, but I think in general I do agree with
> the comments and it looks like all the identified implementation are
> doing the same thing here..
>
> I don't see any strong need to encode the output length of the PRF into
> the input data especially since we are using hardcoded output lengths in
> these cases. That said, I'm not against keeping it there for the IMSK
> derivation since that particular case seemed to be explicitly defined as
> using a 2-octet field in network byte order (and all the known
> implementations doing exactly that). IMHO, the other cases should not be
> modified to try to be consistent with this.
>
> While I do understand the benefits of having an explicit fixed delimiter
> "\0" between the label and seed to enforce unique interpretation if two
> labels were to have same prefix, I don't see that as a critical issue in
> any of the instances used within TEAP due to no such common prefix case
> exist nor do we even use TLS-PRF with the same secret/key. Furthermore,
> RFC 5246 does not mandate or even discuss such delimiter.
>
> There is no need to convert an empty seed to 0x00 or anything else.
> TLS-PRF can be used with secret=something, label=ASCII string,
> seed=0-length data) without issues.
>
> If we want to define a new TEAP-PRF() function, I'd prefer it to be
> using consistent terminology with TLS-PRF in RFC 5246 (and well, to
> extend possible, also be as consistent as can be with the TLS-Exporter
> use in RFC 8446). This would also mean not trying to enforce some 0x00
> delimiter or length in context data. At its simplest and only with TLS
> v1.2 in mind for clarity here, this could look something like
>
> TEAP-PRF(secret, label, seed, output length) =
> PRF(secret, label, seed) outputting "output length" octets
>
> label = ASCII string, no "\x0" termination
> seed = arbitrary binary data (including possibility of 0-length empty
> case)
>
> With this, we would have following:
> IMSK = First 32 octets of TEAP-PRF(EMSK, "teapbind...@ietf.org", 0x00 |
> 0x00 | 0x40, 64)
> IMCK[j] = TEAP-PRF(S-IMCK[j-1], "Inner Methods Compound Keys", IMSK[j], 60)
> MSK = TEAP-PRF(S-IMCK[j], "Session Key Generating Function", , 64)
> EMSK = TEAP-PRF(S-IMCK[j], "Extended Session Key Generating Function",
> , 64)
>
> RFC 5295 rules about EMSK use for USRK/DSRK applies for the first one of
> these and it does seem to give justification for the seed to have "\0"
> and "length" (as 2-octet unsigned integer in network byte order). While
> one could claim that the rules for DSUSRK derivation applies to those
> other instances and as such, would require 0x00 and length to be added
> around the seed shown above, I'd note that there does not seem to be any
> MUST statement about that in RFC 5295 and as such, I think the versions
> described above (and the ones used in known implementations today) seem
> to be justifiable especially taken into account the unique label string
> prefixes and fixed length of output data.
>
> --
> Jouni MalinenPGP id EFC895FA
>
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] Proposed resolution for TEAP errata 5127

[Joseph Salowey]

On Fri, Oct 23, 2020 at 9:11 AM Jouni Malinen  wrote:

> On Wed, Oct 21, 2020 at 02:14:45PM -0700, Joseph Salowey wrote:
> > On Wed, Oct 21, 2020 at 12:11 PM Jouni Malinen  wrote:
> >
> > > On Wed, Oct 21, 2020 at 09:30:33AM -0700, Joseph Salowey wrote:
> > > > Errata 5127: https://www.rfc-editor.org/errata/eid5127
> > > > Proposed State: Verified
> > > > Revision:
> > > > Section 5.2.
> > > > OLD
> > > >
> > > > IMSK = First 32 octets of TLS-PRF(EMSK, "teapbind...@ietf.org" |
> > > >  "\0" | 64)
> > > >
> > > > NEW
> > > >
> > > > IMSK = First 32 octets of TLS-PRF(EMSK, "teapbind...@ietf.org" |
> > > >'/0', 64)
> > >
> > > Why would this change "\0" to '/0'?
> > >
> > > [Joe] that was my mistake should be "/0"
> >
> >
> > > How is that 64 supposed to be encoded if it is the "seed" argument to
> > > PRF(secret, label, seed) define in RFC 5246 Section 5?
> > >
> > >
> > [Joe] 7170 says "length is the 2-octet unsigned integer in network byte
> > order"
>
> It does, but how would one know that this particular 64 is "length"?
> This "64" argument is the "seed" argument to PRF and that could be any
> arbitrary data.. The length of TLS-PRF output is meta data that is not
> passed to the PSK() defined in RFC 5246 directly as an argument, i.e.,
> inclusion of the output length in the seed is something that RFC 7170 is
> doing here for some reason and it could have included any other
> arbitrary seed value here for that matter.. IMHO, this is too vague and
> it would be better to spell out the exact contents of the seed value
> (0x00 | 0x40 im this particular case shown here or 0x00 | 0x00 | 0x40 if
> following the proposal below).
>
>
[Joe]  The length is called out as 64 octets in the sentence just before
this, to me this is not very vague.   However, I do agree that specifying
the exact encoding would be even clearer.  Here is a proposed revision that
I think addresses this and the comment later on in the message:

IMSK = First 32 octets of TLS-PRF(EMSK, "teapbind...@ietf.org",
 0x00 | 0x00 | 0x40)

 where "|" denotes concatenation and the TLS-PRF is defined in
  [RFC5246] as

 PRF(secret, label, seed) = P_(secret, label | seed).

 the secret is the EMSK from the inner method, the label is
 "teapbind...@ietf.org" consisting of the ASCII value for the
 label "teapbind...@ietf.org" (without quotes),  the seed
 consists of the "\0" null delimiter (0x00) and 2-octet unsigned
 integer length in network byte order (0x00 | 0x4) specified
 in [RFC5295]


> > > Using P_hash(EMSK, "teapbind...@ietf.org" | 0x00 | 0x00 | 0x40) looks
> > > correct, but it looks strange to me if we are trying to include the
> > > first 0x00 at the end of the "label" argument to PRF(secret, label,
> > > seed) especially when the label is define to be "an ASCII string. It
> > > should be included in the exact form it is given without a length byte
> > > or trailing null character". I would have expected
> > > "teapbind...@ietf.org" to be the "label" while 0x00 | 0x00 | 0x40
> would
> > > be the "seed". In other words:
> > >
> > > IMSK = First 32 octets of TLS-PRF(EMSK, "teapbind...@ietf.org",
> > >   0x00 | 0x00 | 0x40).
> > >
> > >
> > [Joe] Yes I agree that is better how about this as the text change
> >
> > IMSK = First 32 octets of TLS-PRF(EMSK, "teapbind...@ietf.org", "\0" |
> 64)
>
> It looks quite strange to me to define a binary seed data as a
> concatenation of a string and an integer. I have the exact same question
> about the encoding of 64 here since this does not describe explicitly
> this instance of 64 to be the "length" which has the particular encoding
> described in RFC 7170. For me, using 0x00 | 0x00 | 0x40 and deleting
> that note about length encoding would be significantly clearer. If that
> is not acceptable, I would still replace "\0" with 0x00 in this context
> since this is not an ASCII string or label anymore, but binary data. And
> in addition to that, the "64" part would need to be replaced with
> something like "TLS-PRF output length" and then the "TLS-PRF output
> length" could be mentioned to be 64 in this instance and the encoding
> for that would be 2-octet unsigned integer in network byte order.
>
> --
> Jouni MalinenPGP id EFC895FA
>
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] draft-ietf-emu-eap-tls13-11: OCSP Stapling

[Joseph Salowey]

On Thu, Oct 22, 2020 at 8:08 AM Eliot Lear 
wrote:

> +1.  How does anyone even do OCSP without having first gotten onto the
> network?
>
>
[Joe] THat is what OCSP stapling is supposed to solve since the OCSP
messages are sent in the TLS handshake.   I believe there are some EAP-TLS
implementations that support OCSP, but I am not sure if it is actually
deployed.


> Eliot
>
> On 21 Oct 2020, at 11:02, Hannes Tschofenig 
> wrote:
>
> Hi all,
>
> this draft mandates OCSCP stapling (for use with TLS 1.3 in EAP-TLS) and I
> believe this is a problem for implementations. This extra burden is IMHO
> unjustified. For the type of deployments where EAP is used there is no need
> for a mandatory certificate revocation checking with OCSP.
>
> Having it optional, like the use of many other TLS extensions, is fine for
> me. FWIW even TLS 1.3, which is used in a more generic environment, does
> not mandate the use of OCSP stapling.
>
> This requirement will make the problem described in
> draft-ietf-emu-eaptlscert worse. I am sure the authors are aware of this
> fact since they are also co-authors of draft-ietf-emu-eaptlscert.
>
> Ciao
> Hannes
> IMPORTANT NOTICE: The contents of this email and any attachments are
> confidential and may also be privileged. If you are not the intended
> recipient, please notify the sender immediately and do not disclose the
> contents to any other person, use it for any purpose, or store or copy the
> information in any medium. Thank you.
> ___
> Emu mailing list
> Emu@ietf.org
> https://www.ietf.org/mailman/listinfo/emu
>
>
> ___
> Emu mailing list
> Emu@ietf.org
> https://www.ietf.org/mailman/listinfo/emu
>
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] Proposed resolution for TEAP errata for 5128

[Joseph Salowey]

On Thu, Oct 22, 2020 at 9:29 AM Oleg Pekar 
wrote:

> I agree that changing the KDF is harmful to existing implementations.
> However, if I understood correctly, Joe's suggestion for IMCK[j] also
> breaks the existing implementation. I still see that we can define a
> unified KDF by changing the API in the RFC but with the same harm to the
> existing implementation in IMCK[j] as in both proposals:
>
> TEAP-PRF (secret, key label, optional data, length) = TLS-PRF(secret, key
> label | 0x00 | optional data, length)
> Joe, thanks for pointing out that RFC 5295 doesn't specify that a 0x00 is
> used to represent no optional data, that was just my mistake.
>
> IMSK:
> Current Microsoft and Cisco implementation: P_hash(EMSK, "
> teapbind...@ietf.org" | 0x00 | 0x00 | 0x40)
> Joe's proposal: P_hash(EMSK, "teapbind...@ietf.org" | 0x00 | 0x00 |
> 0x40), the same, just the API correction
> Unified KDF proposal: TEAP-PRF(EMSK, "teapbind...@ietf.org",  data>, 64) = P_hash(EMSK, "teapbind...@ietf.org" | 0x00 | 0x00 | 0x40)
> --- no implementation change
>
> IMCK[j]:
> Current Microsoft and Cisco implementation: P_hash(S-IMCK[j-1], "Inner
> Methods Compound Keys” | IMSK[j])
> Joe's proposal: P_hash(S-IMCK[j-1], "Inner Methods Compound Keys" |
> IMSK[j] | 0x00 | 0x3C)
> Unified KDF proposal: TEAP-PRF(S-IMCK[j-1], "Inner Methods Compound Keys",
> IMSK[j], 60) = P_hash(S-IMCK[j-1], "Inner Methods Compound Keys" | IMSK[j]
> | 0x00 | 0x3C)
> --- implementation change
>

[Joe] That was my initial proposal, but based on Jorge's comment it is
modified to:

IMCK[j] = TLS-PRF(S-IMCK[j-1], "Inner Methods Compound Keys", IMSK[j])  to
generate a length of 60 bytes
IMCK[j] = P_hash(S-IMCK[j-1], "Inner Methods Compound Keys” | IMSK[j])


>
> MSK:
> Current Microsoft and Cisco implementation: P_hash(S-IMCK[j], "Session Key
> Generating Function” | 0x00 | 0x00 | 0x40)
> Unified KDF proposal: TEAP-PRF(S-IMCK[j], "Session Key Generating
> Function”, , 64) = P_hash(S-IMCK[j], "Session Key
> Generating Function” | 0x00 | 0x00 | 0x40)
> --- no implementation change
>
> [Joe] This is the one we have not discussed yet.  This derivation is also
ambiguous.  THis section does not reference 5295.  It's not clear if the
original intent was to include the length in the hash or not.  I think
there are a few interpretations:

1. TLS-PRF(S-IMCK[j], "Session Key Generating Function")  iterated to
generate 64 bytes = P_hash(S-IMCK[j], "Session Key Generating Function”)
2. TLS-PRF(S-IMCK[j], "Session Key Generating Function", 64)  iterated to
generate 64 bytes = P_hash(S-IMCK[j], "Session Key Generating Function” |
0x00 | 0x40)
3. (Follow 5295 parameters) TLS-PRF(S-IMCK[j], "Session Key Generating
Function", "\0" | 64) = P_hash(S-IMCK[j], "Session Key Generating Function”
| 0x00 | 0x00 | 0x40)

I think 1 or 2 is what was probably originally intended, however it seems
that 3 is what has been implemented.  Do we have agreement on this is what
current implementations do?





> Jorge, please correct me if I misinterpret the Microsoft implementation.
>
> On Thu, Oct 22, 2020 at 6:55 PM Joseph Salowey  wrote:
>
>>
>>
>> On Thu, Oct 22, 2020 at 6:59 AM Oleg Pekar 
>> wrote:
>>
>>> Hi all,
>>> Speaking about both errata 5127 and 5128, I think we need to align all
>>> key derivation calls in TEAP RFC with the same rule/format to make the RFC
>>> easier to understand. This can be achieved by introducing a unified single
>>> PRF function that will be called from all the relevant RFC locations. For
>>> me it sounds better than if we align just part of KDF calls with RFC 5295
>>> (where the output length is included into seed). Also: in some KDF calls we
>>> do have optional data and in some no. This could be also unified.
>>>
>>> [Joe] I don't think this was the original intent of the document.  The
>> IMSK derivation referenced 5295 while the others just reference the TLS
>> PRF.  I think to unify them would require a document update and I'm not
>> sure what we would gain especially if we have implementations that do
>> this.
>>
>>
>>> So I would suggest introducing:
>>> TEAP-PRF (secret, key label, optional data, length) = TLS-PRF(secret,
>>> key label | 0x00 | optional data, length)
>>> where a single byte 0x00 is used for no optional data, length is a
>>> 2-octet unsigned integer in network byte order.
>>>
>>> [Joe] I don't think that 5295 specifies that a 0x00 is used to represent
>> no optional data.  Did you see this in the spec? It may be ambiguous, b

Re: [Emu] Proposed resolution for TEAP errata for 5128

[Joseph Salowey]

On Thu, Oct 22, 2020 at 6:59 AM Oleg Pekar 
wrote:

> Hi all,
> Speaking about both errata 5127 and 5128, I think we need to align all key
> derivation calls in TEAP RFC with the same rule/format to make the RFC
> easier to understand. This can be achieved by introducing a unified single
> PRF function that will be called from all the relevant RFC locations. For
> me it sounds better than if we align just part of KDF calls with RFC 5295
> (where the output length is included into seed). Also: in some KDF calls we
> do have optional data and in some no. This could be also unified.
>
> [Joe] I don't think this was the original intent of the document.  The
IMSK derivation referenced 5295 while the others just reference the TLS
PRF.  I think to unify them would require a document update and I'm not
sure what we would gain especially if we have implementations that do
this.


> So I would suggest introducing:
> TEAP-PRF (secret, key label, optional data, length) = TLS-PRF(secret, key
> label | 0x00 | optional data, length)
> where a single byte 0x00 is used for no optional data, length is a 2-octet
> unsigned integer in network byte order.
>
> [Joe] I don't think that 5295 specifies that a 0x00 is used to represent
no optional data.  Did you see this in the spec? It may be ambiguous, but I
think the intent is that optional data is just omitted if it is not
provided.



> Then:
> IMSK = First 32 octets of TEAP-PRF(EMSK, "teapbind...@ietf.org", 64) =
> TLS-PRF(EMSK, "teapbind...@ietf.org" | 0x00 | 0x00 | 0x00 | 0x40)
> IMCK[j] = TEAP-PRF(S-IMCK[j-1], "Inner Methods Compound Keys", IMSK[j],
> 60) = TLS-PRF(S-IMCK[j-1], "Inner Methods Compound Keys" | 0x00 | IMSK[j] |
> 0x00 | 0x3C)
> MSK = TEAP-PRF(S-IMCK[j], "Session Key Generating Function”, 64) =
> TLS-PRF(S-IMCK[j], "Session Key Generating Function" | 0x00 | 0x00 | 0x00 |
> 0x40)
> EMSK = TEAP-PRF(S-IMCK[j], ”Extended Session Key Generating Function”, 64)
> = TLS-PRF(S-IMCK[j], "Extended Session Key Generating Function" | 0x00 |
> 0x00 | 0x00 | 0x40)
>
> This may change the existing implementation but will make it more clear -
> need to create and call just one KDF function.
>
> We can remove 0x00 that comes after the key label - while it is required
> by RFC 5295. But there the key label is also ASCII printable string. Joe,
> do you remember what was the motivation to put 0x00 after the key label
> parameter?
>

[Joe] the null after the key label is to provide a delimiter between the
key label and optional data.  Since the optional data can be arbitrary
content the null prevents two different lablels with specially crafted
optional data from deriving the same key.


>
> Oleg
>
>
> On Thu, Oct 22, 2020 at 2:54 AM Joseph Salowey  wrote:
>
>> (I accidentally dropped this list from the conversation)
>>
>> On Wed, Oct 21, 2020 at 4:48 PM Jorge Vergara 
>> wrote:
>>
>>> >[Joe] Yes this is a concern and I think your interpretation of the
>>> current document is also valid.  There may be more than one
>>> implementation.  So what you implemented was:
>>>
>>> >
>>>
>>> >IMCK[j] = TLS-PRF(S-IMCK[j-1], "Inner Methods Compound Keys", IMSK[j])
>>> = P_(S-IMCK[j-1], "Inner Methods Compound Keys" | IMSK[j])
>>>
>>>
>>>
>>> Yes, this is what I implemented. As you mentioned, there are multiple
>>> possible interpretations of this since the TEAP usage is incorrect.
>>> However, my implementation does interop with at least 2 large vendor
>>> implementations. If the implementations were using different calculations
>>> here, the Wi-Fi/Ethernet connections that depend on the MSK would fail. But
>>> since connections work, I can assume we are all using the same
>>> implementation and arriving at the same MSK. Cisco is one of the
>>> implementations that I have tested against which is why I was hoping Oleg
>>> may offer more context as to what he has seen.
>>>
>>>
>>>
>> [Joe] I can hope Jouni can chime in on this as well.  I think the
>> original intent was to not include the length as is your suggestion.
>>
>>
>>
>>> >[Joe] Does the revision in 5167 match you implementation ( I don't
>>> think Jouni's comment changes the underly calculation, just its
>>> representation)?
>>>
>>>
>>>
>>> I have not implemented this portion of the RFC as I found it too unclear
>>> to work with. Thus I can’t comment on what implementations may be doing.
>>> However, I agree with the current revision in 5167 as the most natur

[Emu] Resolution of TEAP Errata 5767

[Joseph Salowey]

Errata 5767: https://www.rfc-editor.org/errata/eid5767
Status: Verified
Revision:

Section 3.3.1 says:

   EAP method messages are carried within EAP-Payload TLVs defined in
   Section 4.2.10.  If more than one method is going to be executed in
   the tunnel, then upon method completion, the server MUST send an
   Intermediate-Result TLV indicating the result.

It should say:

   EAP method messages are carried within EAP-Payload TLVs defined in
   Section 4.2.10.  Upon completion of each EAP authentication method in
   the tunnel, the server MUST send an Intermediate-Result TLV
   indicating the result.

Section 3.3.3 says:

  The Crypto-Binding TLV and Intermediate-Result TLV MUST be included
  to perform cryptographic binding after each successful EAP method in a
  sequence of one or more EAP methods.

It should say:

  The Crypto-Binding TLV and Intermediate-Result TLV MUST be included
  to perform cryptographic binding after each successful EAP authentication
  method in a sequence of one or more EAP methods.

Section 3.8.3 says:

   Upon successful completion of the EAP method in Phase 2, the peer and
   server exchange a Crypto-Binding TLV to bind the inner method with
   the outer tunnel and ensure that a man-in-the-middle attack has not
   been attempted.

It should say:

   Upon successful completion of the EAP authentication method in Phase 2,
   the peer and server exchange a Crypto-Binding TLV to bind the inner
   method with the outer tunnel and ensure that a man-in-the-middle attack
   has not been attempted.

Section 4.2.11 says:

   The Intermediate-Result TLV provides support for acknowledged
   intermediate Success and Failure messages between multiple
   inner EAP methods within EAP.

It should say:

  The Intermediate-Result TLV provides support for acknowledged
  intermediate Success and Failure messages after each inner EAP
  authentication method.

Section 4.2.13 says:

 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.

It should say:

 It MUST be included with the Intermediate-Result TLV to perform
 cryptographic binding after each successful EAP authentication
 method in a sequence of EAP methods, before proceeding with
 another inner EAP method.

Notes:

TEAP description is somewhat vague in discussion about "EAP methods" vs.
"EAP authentication methods" as it comes to the EAP methods performed in
Phase 2 within the TLS tunnel. RFC 3748 defines Identity request/response
as an EAP method. However, this method is not an "authentication method"
which is a special case of an method where the Type is 4 or greater.

RFC 7170 uses correct terminology in the first paragraph of Section 3.3.1
when talking about multiple authentication methods not being allowed by RFC
3748 in a single EAP conversation. However, many, but not all, of the
following "[EAP] method" instances are actually referring to "[EAP]
authentication method". This results in incorrect claims on when the
Intermediate-Result TLV and Crypto-Binding TLV are used. They are not used
after an EAP non-authentication method like Identity (e.g., see the example
in C.3); they are used after each EAP authentication method like EAP-pwd.

Furthermore, the comment about "more than one method is going to be
executed in the tunnel" does not sound accurate. This applies even if only
a single EAP authentication method is executed in the tunnel (Identity
method is not required to be executed). The proposed text in this errata
entry addresses these two issues in Section 3.3.1. The following additional
changes would be needed to make rest of the specification use the terms
more accurately:

3.3.3: "after each successful EAP method" --> "after each successful EAP
authentication method"
3.8.3: "completion of the EAP method" --> "completion of the EAP
authentication method"
4.2.11: "between multiple inner EAP methods within EAP" --> "after each
inner EAP authentication method"
4.2.13: "after each successful EAP method" --> "after each successful EAP
authentication method"
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] Proposed resolution for TEAP errata for 5128

[Joseph Salowey]

(I accidentally dropped this list from the conversation)

On Wed, Oct 21, 2020 at 4:48 PM Jorge Vergara 
wrote:

> >[Joe] Yes this is a concern and I think your interpretation of the
> current document is also valid.  There may be more than one
> implementation.  So what you implemented was:
>
> >
>
> >IMCK[j] = TLS-PRF(S-IMCK[j-1], "Inner Methods Compound Keys", IMSK[j]) =
> P_(S-IMCK[j-1], "Inner Methods Compound Keys" | IMSK[j])
>
>
>
> Yes, this is what I implemented. As you mentioned, there are multiple
> possible interpretations of this since the TEAP usage is incorrect.
> However, my implementation does interop with at least 2 large vendor
> implementations. If the implementations were using different calculations
> here, the Wi-Fi/Ethernet connections that depend on the MSK would fail. But
> since connections work, I can assume we are all using the same
> implementation and arriving at the same MSK. Cisco is one of the
> implementations that I have tested against which is why I was hoping Oleg
> may offer more context as to what he has seen.
>
>
>
[Joe] I can hope Jouni can chime in on this as well.  I think the original
intent was to not include the length as is your suggestion.



> >[Joe] Does the revision in 5167 match you implementation ( I don't think
> Jouni's comment changes the underly calculation, just its representation)?
>
>
>
> I have not implemented this portion of the RFC as I found it too unclear
> to work with. Thus I can’t comment on what implementations may be doing.
> However, I agree with the current revision in 5167 as the most natural
> interpretation. If others have implemented this portion of the RFC then
> certainly their comments would be welcome.
>
>
> By the way, we’ve dropped the EMU group on our replies here – not sure if
> intentional or not.
>
>
>
> Jorge Vergara
>
>
>
> *From:* Joseph Salowey 
> *Sent:* Wednesday, October 21, 2020 4:36 PM
> *To:* Jorge Vergara 
> *Subject:* Re: Proposed resolution for TEAP errata for 5128
>
>
>
>
>
>
>
> On Wed, Oct 21, 2020 at 3:20 PM Jorge Vergara 
> wrote:
>
> In theory I agree this is a possible resolution. However, this doesn’t
> match any of the current TEAP implementations that I am aware of. Perhaps
> Oleg can weigh in as well in terms of what he’s seen.
>
>
>
> I believe all current implementations treat 60 as the desired output
> length without treating as a seed. In terms of P_, this means
> implementations are performing the calculation without a seed.
>
>
>
> RFC 5246 defines the TLS 1.2 PRF as:
>
> PRF(secret, label, seed) = P_(secret, label + seed)
>
>
>
> So the calculation implementations are currently performing with an empty
> seed ends up as:
>
> P_(secret, label)
>
>
>
> Note that in RFC 5295, the length *is* explicitly mentioned as being
> concatenated with the label
>
> USRK = KDF(EMSK, key label | "\0" | optional data | length)
>
>
>
> RFC 5295 is mentioned earlier in the TEAP RFC, in the section covered by
> errata 5127. *However* it is not mentioned in this portion of the RFC.
> Since this calculation is not on an EMSK, I do not believe RFC 2395 applies
> and this is likely why implementations went with the seedless
> P_(secret, label) calculation instead.
>
>
>
> Is there concern about updating the RFC in a way that breaks existing
> implementations?
>
>
>
> [Joe] Yes this is a concern and I think your interpretation of the current
> document is also valid.  There may be more than one implementation.  So
> what you implemented was:
>
>
>
> IMCK[j] = TLS-PRF(S-IMCK[j-1], "Inner Methods Compound Keys", IMSK[j]) =
> P_(S-IMCK[j-1], "Inner Methods Compound Keys" | IMSK[j])
>
>
>
> taken out to 60 bytes.  The problem is that the TEAP spec references a
> TLS-PRF in a way that it does not define.  I think the errata points out
> the definition that should be used:
>
>
>
> PRF(secret, label, seed) = P_(secret, label + seed)
>
>
>
> That does not include length so the 60 in the original definition is
> ambiguous.   The new text would then be something like:
>
>
>
> IMCK[j] = TLS-PRF(S-IMCK[j-1], "Inner Methods Compound Keys", IMSK[j])
> to generate a length of 60 bytes
>
>
>
> Does the revision in 5167 match you implementation ( I don't think
> Jouni's comment changes the underly calculation, just its representation)?
>
>
>
>
>
>
>
>
>
>
>
> Jorge Vergara
>
>
>
> *From:* Joseph Salowey 
> *Sent:* Wednesday, October 21, 2020 2:34 PM
> *To:* EMU WG ; Jouni Malinen ; Jorge Vergara <
&

[Emu] Proposed resolution for TEAP errata 5765

[Joseph Salowey]

Errata 5765: https://www.rfc-editor.org/errata/eid5765
Proposed Status: Verified
Revision: (unmodified from original posting)

Section 4.2.2 says:

   M

  Mandatory, set to one (1)

It should say:

   M

  0 (Optional)

Notes:

Authority-ID TLV is used only as an Outer TLV (in TEAP/Start) and Section
4.3.1 mandates all Outer TLVs to be marked as optional ("Outer TLVs MUST be
marked as optional"). As such, Section 4.2.2 is incorrect in claiming the
Authority-ID TLV to use M=1.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

[Emu] Proposed resolution for TEAP errata for 5128

[Joseph Salowey]

Errata 5128: https://www.rfc-editor.org/errata/eid5128
Proposed State: Verified
Revision:

Section 5.2. says


IMCK[j] = TLS-PRF(S-IMCK[j-1], "Inner Methods Compound Keys",
IMSK[j], 60)

It should say:

IMCK[j] = TLS-PRF(S-IMCK[j-1], "Inner Methods Compound Keys", IMSK[j] | 60)

Note:
According to

RFC5246 The Transport Layer Security (TLS) Protocol Version 1.2

5. HMAC and the Pseudorandom Function

"TLS's PRF is created by applying P_hash to the secret as:

PRF(secret, label, seed) = P_(secret, label + seed)"

In terms of P_ this would look like the following with the length
represented as a 2 byte value in network byte order:

IMCK[j] = P_(S-IMCK[j-1], "Inner Methods Compound Keys" | IMSK[j] |
0x00 | 0x3C)
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] Proposed resolution for TEAP errata 5127

[Joseph Salowey]

On Wed, Oct 21, 2020 at 12:11 PM Jouni Malinen  wrote:

> On Wed, Oct 21, 2020 at 09:30:33AM -0700, Joseph Salowey wrote:
> > Errata 5127: https://www.rfc-editor.org/errata/eid5127
> > Proposed State: Verified
> > Revision:
> > Section 5.2.
> > OLD
> >
> > IMSK = First 32 octets of TLS-PRF(EMSK, "teapbind...@ietf.org" |
> >  "\0" | 64)
> >
> > NEW
> >
> > IMSK = First 32 octets of TLS-PRF(EMSK, "teapbind...@ietf.org" |
> >'/0', 64)
>
> Why would this change "\0" to '/0'?
>
> [Joe] that was my mistake should be "/0"


> How is that 64 supposed to be encoded if it is the "seed" argument to
> PRF(secret, label, seed) define in RFC 5246 Section 5?
>
>
[Joe] 7170 says "length is the 2-octet unsigned integer in network byte
order"


> > Notes:
> > According to
> >
> > RFC5246 The Transport Layer Security (TLS) Protocol Version 1.2
> >
> > 5. HMAC and the Pseudorandom Function
> >
> > "TLS's PRF is created by applying P_hash to the secret as:
> >
> > PRF(secret, label, seed) = P_(secret, label + seed)"
> >
> > In this case the seed is the 2-byte length of the output as defined by
> RFC
> > 5295.  In terms of P_ the derivation would look like:
> >
> > IMSK = P_(EMSK, "teapbind...@ietf.org" | 0x00 | 0x00 | 0x40)
>
> Using P_hash(EMSK, "teapbind...@ietf.org" | 0x00 | 0x00 | 0x40) looks
> correct, but it looks strange to me if we are trying to include the
> first 0x00 at the end of the "label" argument to PRF(secret, label,
> seed) especially when the label is define to be "an ASCII string. It
> should be included in the exact form it is given without a length byte
> or trailing null character". I would have expected
> "teapbind...@ietf.org" to be the "label" while 0x00 | 0x00 | 0x40 would
> be the "seed". In other words:
>
> IMSK = First 32 octets of TLS-PRF(EMSK, "teapbind...@ietf.org",
>   0x00 | 0x00 | 0x40).
>
>
[Joe] Yes I agree that is better how about this as the text change

IMSK = First 32 octets of TLS-PRF(EMSK, "teapbind...@ietf.org", "\0" |  64)


>
> Please note that this is followed by this explanation:
>
>  where "|" denotes concatenation, EMSK is the EMSK from the inner
>  method, "teapbind...@ietf.org" consists the ASCII value for the
>  label "teapbind...@ietf.org" (without quotes), "\0" = is a NULL
>  octet (0x00 in hex), length is the 2-octet unsigned integer in
>  network byte order, and TLS-PRF is the PRF negotiated as part of
>  TLS handshake [RFC5246].
>
> Using "64" as the seed would require the reader to interpret 64 to be
> the "length" and use the "2-octet unsigned integer in network byte
> order" from that to determine the exact encoding of the seed. And the
> first 0x00 as part of the label to TLS-PRF would be be confusing as well
> with this explanation that is clearly defining the label without
> including the explicitly noted "\0" after the label.
>
> --
> Jouni MalinenPGP id EFC895FA
>
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

[Emu] Proposed resolution for TEAP errata 5127

[Joseph Salowey]

Errata 5127: https://www.rfc-editor.org/errata/eid5127
Proposed State: Verified
Revision:
Section 5.2.
OLD

IMSK = First 32 octets of TLS-PRF(EMSK, "teapbind...@ietf.org" |
 "\0" | 64)

NEW

IMSK = First 32 octets of TLS-PRF(EMSK, "teapbind...@ietf.org" |
   '/0', 64)

Notes:
According to

RFC5246 The Transport Layer Security (TLS) Protocol Version 1.2

5. HMAC and the Pseudorandom Function

"TLS's PRF is created by applying P_hash to the secret as:

PRF(secret, label, seed) = P_(secret, label + seed)"

In this case the seed is the 2-byte length of the output as defined by RFC
5295.  In terms of P_ the derivation would look like:

IMSK = P_(EMSK, "teapbind...@ietf.org" | 0x00 | 0x00 | 0x40)
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

[Emu] Resolution of TEAP Errata

[Joseph Salowey]

I'll be posting proposed errata revisions for a short, 1 week, final review
before sending it off to the Area Director (Roman) who has the
responsibility of the final action.  For more information how errata are
handled and the please see [1].

Please take a little time to review the errata resolution to make sure that
they match what was discussed on the list and in meetings.

Thanks,

Joe

[1] https://www.ietf.org/about/groups/iesg/statements/processing-rfc-errata/
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] I-D Action: draft-ietf-emu-tls-eap-types-01.txt

[Joseph Salowey]

On Wed, Sep 2, 2020 at 7:54 AM Alan DeKok  wrote:

> On Sep 2, 2020, at 3:30 AM, John Mattsson 
> wrote:
> >> I can tell you what Windows is doing for TLS 1.2; and Windows interops
> with all the TEAP implementations that I know of, so others are likely
> doing the same. We're using the MAC function in the case of a CBC block
> cipher suite, or PRF hash function in the case of an AEAD cipher suite.
> Yes, it's unspecified, but I believe most TLS libraries abstracts the
> difference away, so it went unnoticed. I imagine it may have gone unnoticed
> by other implementations as well.
> >
> > Should we document this behavior for TLS 1.2 in the draft? I.e. the PRF
> hash function in HMAC mode for AEAD cipher suites and the MAC function for
> non-AEAD cipher suites.
>
>   Yes.  Any suggested text?  I'm not overly familiar with TLS 1.3, so I
> don't want to suggest the wrong thing.
>
>
[Joe]  I think you should treat them as 3 distinct cases to make sure it is
clear.  For TLS 1.3 I like John's second phrasing better as it aligns
better with TLS 1.3 terminology:

"For TLS 1.3 the hash function used is the same as the ciphersuite hash
function negotiated for HKDF in the key schedule."  (section 7.1 of 8446)


> >> Rather than locking in another dependency such as SHA256, I wonder if
> this calculation should also use a hash function derived from the TLS
> handshake?
> >
> > That is a much better idea! It is not necessary to update any TEAP TLS
> 1.2 code, but it definitely feels like a worthwhile thing to do when the
> implementation is anyway updated for TLS 1.3.
>
>   Can we use the same hash functions as above?  If so, what would the text
> look like?
>
>
[Joe] Moving away from SHA-1 is a good idea as it will only raise questions
moving forward.  For TLS 1.3 I think you could use the same text, but I
would look to Jorge to make sure we get it correct for PEAP.   TEAP should
also use the Hash from HKDF in TLS 1.3.


>   Alan DeKok.
>
> ___
> Emu mailing list
> Emu@ietf.org
> https://www.ietf.org/mailman/listinfo/emu
>
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

[Emu] Handling Large Certificates and Long Certificate Chains submitted for publication

[Joseph Salowey]

Handling Large Certificates and Long Certificate Chains in TLS-based EAP
Methods (draft-ietf-emu-eaptlscert-05) has been submitted to the IESG for
publication.  The shepherd write-up can be found  here -
https://datatracker.ietf.org/doc/draft-ietf-emu-eaptlscert/shepherdwriteup/

Cheers,

Joe
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

[Emu] Publication has been requested for draft-ietf-emu-eaptlscert-05

[Joseph Salowey via Datatracker]

Joseph Salowey has requested publication of draft-ietf-emu-eaptlscert-05 as 
Informational on behalf of the EMU working group.

Please verify the document's state at 
https://datatracker.ietf.org/doc/draft-ietf-emu-eaptlscert/


___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] Preparations for Friday

[Joseph Salowey]

We will also need a note taker.  If you are willing to take minutes, please
contact the chairs.

Link for notes (CodiMD)
https://codimd.ietf.org/notes-ietf-108-emu
Link to attend session (requires registration)
   https://meetings.conf.meetecho.com/ietf108/?group=emu==1


On Tue, Jul 28, 2020 at 2:10 AM Mohit Sethi M  wrote:

> Dear all,
>
> Instead of the usual 120 minutes, we have a 50 minute session for EMU @
> IETF 108 on Friday, July 31st. Here is our current agenda for the meeting:
> https://datatracker.ietf.org/doc/agenda-108-emu/
>
> As you notice, the agenda is rather packed. There is no possibility to
> extend the duration of the session and we intend to make a hard stop
> after 50 minutes.
>
> Therefore, we strongly recommend all of you to familiarize yourself with
> meetecho:
> https://www.ietf.org/how/meetings/108/session-participant-guide/. This
> will hopefully ensure that we don't have any teething issues on Friday.
> Some of the meetecho controls are not obvious:
>
> - Enter video queue != Enter audio queue. You have to request both if
> you want to share both audio and video.
> - Instead of mute/unmute, the tool uses send audio/stop audio.
>
> You can also use the meetecho test environment here:
> https://gce.conf.meetecho.com/conference/?group=prova.
>
> We also encourage you to read the drafts (and related mailing list
> discussions) before Friday.
>
> Joe and Mohit
>
>
> ___
> Emu mailing list
> Emu@ietf.org
> https://www.ietf.org/mailman/listinfo/emu
>
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] TEAP - RFC 7170 - Errata ID 5768

[Joseph Salowey]

On Mon, Jun 29, 2020 at 6:49 AM Oleg Pekar 
wrote:

> Jorge, Joe, thank you for your comments. So the updated proposal should be:
>
> 1) In Section "4.2.13.  Crypto-Binding TLV" make "EMSK Compound MAC" and
> "MSK Compound MAC" fields variable length depending on the number of output
> bits of the MAC function negotiated by TLS protocol. A field "Compound MAC
> Length" of size 1 octet is added after the "Nonce" field to represent the
> length of each of "EMSK Compound MAC" and "MSK Compound MAC" fields. The
> minimum length for each Compound MAC field is 20 octets (to honor the
> original RFC fixed size and to allow usage of SHA-1 - that is still used in
> TLS 1.2 - to provide MAC without padding). The length should never be less
> than 20 octets since there are no ciphers supported by TLS 1.2 with a
> digest of less than 160 bits output size. Therefore if "Compound MAC
> Length" field value is less than 20 then the Crypto-binding TLV should be
> considered of erroneous format and handled as described in section 3.6.
> Error Handling. The value of the length field of the whole Crypto-Binding
> TLV should be calculated accordingly (currently fix 76 octets).
>
> [Joe] I'm not sure I see the need to for a length here.  Isn't the MAC
algorithm known before this message is processed and therefore the length
should be known?  The document should clarify how the MAC algorithm is
determined for TLS 1.2 and TLS 1.3. The length could then be defined as the
length of the output of the MAC function.


> The updated structure of Crypto-Binding TLV:
>
> The Crypto-Binding TLV is defined as follows:
>
> 0   1   2   3
> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>|M|R| TLV Type  |Length |
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>|Reserved   |Version|  Received Ver.| Flags|Sub-Type|
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>|   |
>~ Nonce ~
>|   |
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>|  Comp MAC Len |
>
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>|   |
>~   EMSK Compound MAC   ~
>|   |
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>|   |
>~MSK Compound MAC   ~
>|   |
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>
> If we would not bump the TEAP protocol version - we still can change the 
> Crypto-Binding TLV version to 2.
>
>
> 2) [This was accepted and stays unchanged]
>
> 3) In Section "5.3.  Computing the Compound MAC" when specifying the list of 
> fields to be placed in the BUFFER" should say "...2  A single octet contains 
> TEAP EAP method type 0x37". However to let this byte play a role in 
> protection of Crypto-Binding TLV I would suggest to place in it the inner EAP 
> method type related to the calculation or 0x0 if no inner EAP method was 
> executed. What are your opinions on this?
>
>
[Joe] I believe the original intent was that the same Compound MAC
construction could be used in multiple protocols (EAP-FAST, PEAP, TEAP).
Using the outer EAP method type would help protect against cross protocol
attacks if this TLV were reused.  If we are going to change the
TLV/protocol version we could revisit this and other aspects of the
compound TLV to validate their security goals and implementation.


>
> Thanks
> Oleg
>
>
> On Tue, May 26, 2020 at 12:29 PM Jorge Vergara 
> wrote:
>
>>
>>
>> *From:* Joseph Salowey 
>> *Sent:* Monday, May 25, 2020 9:27 PM
>> *To:* Jorge Vergara 
>> *Cc:* Oleg Pekar ; Jouni Malinen ;
>> EMU WG 
>> *Subject:* Re: [Emu] TEAP - RFC 7170 - Errata ID 5768
>>
>>
>>
>>
>>
>>
>>
>> On Fri, May 22, 2020 at 1:18 PM Jorge Vergara > 40microsoft@dmarc.ietf.org> wrote:
>>
>> My review of this errata and the current responses from Oleg:
>>
>>
>>

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

[Joseph Salowey]

On Mon, Jun 22, 2020 at 9:06 PM Jorge Vergara 
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 
> *Sent:* Monday, June 22, 2020 8:53 PM
> *To:* Oleg Pekar 
> *Cc:* Jorge Vergara ; Jouni Malinen ;
> EMU WG 
> *Subject:* Re: [Emu] draft-dekok-emu-tls-eap-types discussion
>
>
>
>
>
>
>
> On Tue, Apr 21, 2020 at 11:02 AM Oleg Pekar 
> 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=02%7C01%7Cjovergar%40microsoft.com%7Cf691061f596040be882d08d81728fe5f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637284812133625099=9B%2BrGF9AduXXuERXbDh4tTTT4I%2BnVjOI1GrLwWJNPkY%3D=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 me

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

[Joseph Salowey]

On Tue, Apr 21, 2020 at 11:02 AM Oleg Pekar 
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
> 
> - 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
> . 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 
> 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 

Re: [Emu] Early allocation request for an EAP Method Type number for draft-ietf-emu-eap-noob

[Joseph Salowey]

There have been some recent reviews  for EAP-NOOB.  I think it would be
prudent to wait until this round of comments are resolved before moving
forward with the request for early allocation.

On Tue, May 26, 2020 at 1:53 AM Mohit Sethi M 
wrote:

> I would add that there is also an early implementation of EAP-TLS-PSK:
> https://github.com/rohitshubham/EAP-TLS-PSK
>
> We had agreed that external PSK authentication for EAP-TLS will use a new
> method type number. The draft for EAP-TLS-PSK (
> https://tools.ietf.org/html/draft-mattsson-emu-eap-tls-psk-00) is still
> in the early stages and will undergo many changes before it can be
> considered for adoption by the working group. However, allocating a method
> type number for EAP-NOOB now would ensure that EAP-TLS-PSK doesn't use the
> same code point.
>
> --Mohit
> On 5/26/20 6:56 AM, Joseph Salowey wrote:
>
> The authors of EAP-NOOB (draft-ietf-emu-eap-noob) have requested early
> allocation of the EAP type code value 56.  If you object to the early code
> point assignment please let the list know why by June 14, 2020.
>
> The criteria for early assignment includes the following:
>
> A.The code points must be from a space designated as "RFC Required",
> "IETF Review", or "Standards Action".  Additionally, requests for early
> assignment of code points from a "Specification Required" registry are
> allowed if the specification will be published as an RFC.
>
> EAP Methods have an allocation policy of Designated Expert, with
> Specification Required.  The specification in this case the
> draft-ietf-emu-eap-noob.
>
> B.  The format, semantics, processing, and other rules related to handling
> the protocol entities defined by the code points henceforth called
> "specifications") must be adequately described in an Internet-Draft.
>
> The specification draft-ietf-emu-eap-noob-00 contains the protocol
> specifics.  There are implementations based on this specification listed
> below
>
> C. The specifications of these code points must be stable; i.e., if there
> is a change, implementations based on the earlier and later specifications
> must be seamlessly interoperable.
>
> Although the document is a 00 document, the predecessor document
> draft-aura-eap-noob
> <https://datatracker.ietf.org/doc/draft-aura-eap-noob/> has been
> discussed for over a year.  This call is a request for working group
> members to review the document and object if the specification is not
> stable.
>
> D. There is sufficient interest in the community for early (pre-RFC)
> implementation and deployment, or that failure to make an early allocation
> might lead to contention for the code point in the field.
>
> Several implementations exist, but it would be good to see if there is
> additional interest in implementing this protocol
>
> The authors note that currently, the following implementations of EAP-NOOB
> exist:
>
> 1. Implementation with wpa_supplicant (client) and hostapd (server):
> https://github.com/tuomaura/eap-noob
>
> 2. Lightweight implementation on Contiki (client only):
> https://github.com/eduingles/coap-eap-noob (Tested with server
> implementation from #1)
>
> 3. Minimal EAP-NOOB (based on #1 with cleaner code and updates to match
> current draft version): https://github.com/Vogeltak/eap-noob
>
> Thanks,
>
> Joe
>
> ___
> Emu mailing listEmu@ietf.orghttps://www.ietf.org/mailman/listinfo/emu
>
>
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] TEAP - RFC 7170 - Errata ID 5768

[Joseph Salowey]

On Fri, May 22, 2020 at 1:18 PM Jorge Vergara  wrote:

> My review of this errata and the current responses from Oleg:
>
>
>
>1. I agree with this proposed resolution. I do think this is an
>important omission that needs to be clarified in the RFC. Otherwise it is
>somewhat guesswork that truncation is the right action. I think the current
>wording leans toward truncation, but I definitely asked this question
>myself while implementing.
>
> [Joe]  Why not just change the TLV to be variable length?  It seems if we
hardcode the length to 100 we risk having the same problem in the future?


>
>1.
>2. This bleeds into Alan’s TLS 1.3 document somewhat, but I agree with
>Jouni that this will need to change when the rest of the document is
>eventually updated to TLS 1.3. There are enough TLS 1.3 related things to
>address in TEAP that I don’t exactly view this as an errata. I view it as a
>needed update, whether in this document, Alan’s document, or both.
>
> [Joe]  I tend to agree that this is not an errata.  However an update to
TEAP should address these.


>
>1.
>2. Agree with Jouni that I don’t see the point of the 0x37 octet, but
>regardless this clarification of how it is encoded is positive (minor)
>change.
>
> [Joe] I think the original reason to include the TEAP method ID in the
specification was to make sure that we differentiated between similar
crypto binding implementations in other protocols such as EAP-FAST.   I
don't think there is much ambiguity here, but I am OK with including 0x37
in the description.


>
>
> Thanks,
>
> Jorge
>
>
>
> *From:* Emu  *On Behalf Of * Oleg Pekar
> *Sent:* Tuesday, May 5, 2020 6:27 AM
> *To:* Jouni Malinen ; EMU WG 
> *Subject:* [Emu] TEAP - RFC 7170 - Errata ID 5768
>
>
>
> Hi Jouni,
>
> I propose the following fix for the issues described in this errata id:
>
> 1) In Section "4.2.13.  Crypto-Binding TLV" make "EMSK Compound MAC" and
> "MSK Compound MAC" fields 32 octets long (currently 20 octets). The MAC
> value is truncated at 32 octets if it is longer than 32 octets or padded to
> a length of 32 octets with zeros to the right if it is less than 32 octets.
> The length of the TLV should be changed to 100 bytes (currently 76).
>
>
>
> The motivation is to keep collision-resistance strength of MAC on 128 bit..
> Hash value truncation is described in "NIST Special Publication 800-107
> Revision 1: Recommendation for Applications Using Approved Hash Algorithms"
> 
>
>
>
>
> 2) In Section "5.3.  Computing the Compound MAC" specify that "MAC is the
> MAC function negotiated in TLS of TEAP Phase 1" (currently it says TLS
> 1.2)
>
>
>
> The motivation is to support TLS 1.2, 1.3 and possibly later TLS versions..
>
>
>
> 3) In Section "5.3.  Computing the Compound MAC" when specifying the list
> of field to be placed in the BUFFER" should say "...2  A single octet
> contains TEAP EAP method type 0x37". Alternatively it could be "...2  A
> single octet contains EAP Type of the inner EAP method related to the
> calculation or 0 if no inner EAP method was executed" (currently "...2  The
> EAP Type sent by the other party in the first TEAP message")
>
>
>
> Please note that there's still a discussion on sending Crypto-Binding TLV
> on "Authentication inner EAP method" or "Inner EAP method that exports MSK"
> only.
>
>
>
> Thanks
>
> Oleg
> ___
> Emu mailing list
> Emu@ietf.org
> https://www.ietf.org/mailman/listinfo/emu
>
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

[Emu] Early allocation request for an EAP Method Type number for draft-ietf-emu-eap-noob

[Joseph Salowey]

The authors of EAP-NOOB (draft-ietf-emu-eap-noob) have requested early
allocation of the EAP type code value 56.  If you object to the early code
point assignment please let the list know why by June 14, 2020.

The criteria for early assignment includes the following:

A.The code points must be from a space designated as "RFC Required",
"IETF Review", or "Standards Action".  Additionally, requests for early
assignment of code points from a "Specification Required" registry are
allowed if the specification will be published as an RFC.

EAP Methods have an allocation policy of Designated Expert, with
Specification Required.  The specification in this case the
draft-ietf-emu-eap-noob.

B.  The format, semantics, processing, and other rules related to handling
the protocol entities defined by the code points henceforth called
"specifications") must be adequately described in an Internet-Draft.

The specification draft-ietf-emu-eap-noob-00 contains the protocol
specifics.  There are implementations based on this specification listed
below

C. The specifications of these code points must be stable; i.e., if there
is a change, implementations based on the earlier and later specifications
must be seamlessly interoperable.

Although the document is a 00 document, the predecessor document
draft-aura-eap-noob  has
been discussed for over a year.  This call is a request for working group
members to review the document and object if the specification is not
stable.

D. There is sufficient interest in the community for early (pre-RFC)
implementation and deployment, or that failure to make an early allocation
might lead to contention for the code point in the field.

Several implementations exist, but it would be good to see if there is
additional interest in implementing this protocol

The authors note that currently, the following implementations of EAP-NOOB
exist:

1. Implementation with wpa_supplicant (client) and hostapd (server):
https://github.com/tuomaura/eap-noob

2. Lightweight implementation on Contiki (client only):
https://github.com/eduingles/coap-eap-noob (Tested with server
implementation from #1)

3. Minimal EAP-NOOB (based on #1 with cleaner code and updates to match
current draft version): https://github.com/Vogeltak/eap-noob

Thanks,

Joe
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

[Emu] Note Taker, Jabber Script and Slides EMU Virtual Interim on 5/22

[Joseph Salowey]

The EMU virtual interim is Friday 2020-05-22 15:00 UTC.  If you are
presenting please send your slides to the chairs.

We are also looking for Note Taker and Jabber Scribe Volunteers.  Please
send the chairs a note if you can help out.

Cheers,

Joe
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

[Emu] Publication has been requested for draft-ietf-emu-eap-tls13-09

[Joseph Salowey via Datatracker]

Joseph Salowey has requested publication of draft-ietf-emu-eap-tls13-09 as 
Proposed Standard on behalf of the EMU working group.

Please verify the document's state at 
https://datatracker.ietf.org/doc/draft-ietf-emu-eap-tls13/


___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] WGLC for draft-ietf-emu-eap-tls13-09

[Joseph Salowey]

The WGLC for this draft has been completed.   Publication will be requested
later this week.

On Sun, Apr 19, 2020 at 3:37 PM Joseph Salowey  wrote:

> This is the second working group last call for EAP-TLS
> (draft-ietf-emu-eap-tls13-09)[1].  The authors submitted a draft to address
> the issues raised during the last working group last call.  Please focus on
> the changes [2] in the latest draft and send any comments to the list by
> May 4, 2020.
>
> Thanks,
>
> Joe
>
> [1] https://datatracker.ietf.org/doc/draft-ietf-emu-eap-tls13/
> [2] https://tools.ietf.org/rfcdiff?url2=draft-ietf-emu-eap-tls13-09.txt
>
>
>
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

[Emu] WGLC for draft-ietf-emu-eap-tls13-09

[Joseph Salowey]

This is the second working group last call for EAP-TLS
(draft-ietf-emu-eap-tls13-09)[1].  The authors submitted a draft to address
the issues raised during the last working group last call.  Please focus on
the changes [2] in the latest draft and send any comments to the list by
May 4, 2020.

Thanks,

Joe

[1] https://datatracker.ietf.org/doc/draft-ietf-emu-eap-tls13/
[2] https://tools.ietf.org/rfcdiff?url2=draft-ietf-emu-eap-tls13-09.txt
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

[Emu] Working Group Call For adoption of draft-aura-eap-noob-08.txt

[Joseph Salowey]

This is a call for adoption of draft-aura-eap-noob-08.txt [1] as a working
group item.  This draft has been discussed in several IETF meetings and
would be the starting point for the working group deliverable for an EAP
method based on "mutual authentication between a peer and a server that is
based on an out-of-band channel."  Please review the draft and indicate
whether you support adoption or not by May 4, 2020.
Thanks,

Joe

[1] https://datatracker.ietf.org/doc/draft-aura-eap-noob/
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

[Emu] EMU@IETF017: Agenda Topics

[Joseph Salowey]

Please send any agenda requests to the chairs at emu-cha...@ietf.org.

Thanks

Joe
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

[Emu] WGLC for draft-ietf-emu-eaptlscert (corrected)

[Joseph Salowey]

Hi Folks,

This is the working group last call for the "Large Certificates in
TLS-based EAP Methods" draft available at
https://datatracker.ietf.org/doc/draft-ietf-emu-eaptlscert/ (
https://tools.ietf.org/html/draft-ietf-emu-eaptlscert-00). Please review
the document and send your comments to the list by 2359 UTC on 16 March
2020.

Note the draft has expired, the authors will resubmit after this call to
address any comments and refresh the draft.  The GH repo for this draft can
be found at: https://github.com/emu-wg/eaptls-longcert.

Thanks,

Joe
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

[Emu] WGLC for draft-davidben-tls13-pkcs1-00

[Joseph Salowey]

Hi Folks,

This is the working group last call for the "Large Certificates in
TLS-based EAP Methods" draft available at
https://datatracker.ietf.org/doc/draft-ietf-emu-eaptlscert/. Please review
the document and send your comments to the list by 2359 UTC on 16 March
2020.

Note the the GH repo for this draft can be found at:
https://github.com/emu-wg/eaptls-longcert

Thanks,

Joe
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] Processing of TEWAP erratum 5127

[Joseph Salowey]

>
>> Could it be that this text refers to RFC 5295:
>>
>>  If an inner method supports export of an Extended Master Session Key
>>  (EMSK), then the IMSK SHOULD be derived from the EMSK as defined in
>>  [*RFC5295*].  The usage label used is "teapbind...@ietf.org", and the
>>  length is 64 octets.  *Optional data parameter is not used in the*
>> * derivation.*
>>
>>
>> USRK = KDF(EMSK, key label | "\0" | optional data | length)
>>
>> Which perhaps is meant to translate to:
>>
>> IMSK = KDF(EMSK, “teapbind...@ietf.org”, 64)
>>
>> But again, only when the inner method supports export of the EMSK.  Note
>> the text below, by the way:
>>
>> USRKs MUST be at least 64 octets in length.
>>
>>
>>
>> However we interpret the text, it seems that either the argument count is
>> wrong or the function is wrong.
>>
>> The following description is then clearly indicating
>> that "\0" is 0x00 and length (that | 64) is "2-octet unsigned integer in
>> network byte order".  That seems to be talking about some binary data
>> and the seed is the only place where such byte order and field size
>> discussion would apply. I'm actually implementing that last one because
>> of that discussion in the RFC.
>>
>> It should also be noted that the "First 32 octets of TLS-PRF(..., 64)"
>> does not make much sense since "TLS-PRF(..., 32)" would cover same. This
>> would seem to imply that "First 32 octets of TLS-PRF" could actually be
>> trying to address that PRF argument mismatch. Anyway, maybe this should
>> simply say:
>>
>> IMSK = TLS-PRF(EMSK, "teapbind...@ietf.org", 0x00 | 0x00 | 0x40, 32)
>> (or with empty seed "" instead of that 3 octet seed)
>>
>>
>>
> I’m really not sure what adding a known seed gets us at this point.
>>
>>
[Joe] The intent is that the IMSK derivation uses the USRK derivation of
RFC 5295.  The label, null and 2-byte length are defined in that
specification.  (P_ is defined in RFC 5246)

IMSK = P_ (EMSK, "teapbind...@ietf.org" | 0x00 | 0x00 | 0x40)

P_ is iterated to generate 64 bytes, the output is truncated to 32.
If we add a parameter to the P_  to define the length, this would be

IMSK = Truncate(P_(EMSK, "teapbind...@ietf.org" | 0x00 | 0x00 | 0x40,
64), 32)


>
>> The "and the length is 64 octets" part just above this is a bit
>> confusing with this, though.
>>
>> [Joe]  In particular its not clear If the same construction should be
used for the other derivations. For example, whether to include the output
length into the data fed into the PRF or not or if there is a null between
the label and the seed.  I believe the intent was the following:
>
> IMCK[j] = TLS-PRF(S-IMCK[j-1], "Inner Methods Compound Keys", IMSK[j], 60)
>>
>>   (this is actually unchanged)
>>
>> IMCK[j] =  P_(S-IMCK[j-1], "Inner Methods Compound Keys", | 0x00 |
IMSK[j] | 0x00 | 0x3C, 60)

> MSK = TLS-PRF(S-IMCK[j], "Session Key Generating Function", "", 64)
>>   (i.e., add the missing empty seed)
>>
>>
MSK = P_(S-IMCK[j], "Session Key Generating Function" | 0x00 | 0x00 |
0x40, 64)

>
>> EMSK = TLS-PRF(S-IMCK[j],
>>   "Extended Session Key Generating Function", "", 64)
>>   (i.e., add the missing empty seed)
>>
>>
EMSK = P_(S-IMCK[j], ""Extended Session Key Generating Function" |
0x00 | 0x00 | 0x40, 64)

>
>>
>>
>> On the last two, entropy is thus borrowed from S-IMCK[j].  Correct?  I
>> don’t have the full flow in my head, but are these indepedently generated
>> on both sides, right?  If so, I don’t see any other alternative to what you
>> are suggesting.
>>
>>
>
[Joe]  THis is not the only the derivation could be interpreted.  The null
after the label and the inclusion of the length are part of RFC 8295 and
not the TLS PRF.   To fix this errata I think we should define the TLS-PRF
to be P_ with a length parameter for TLS 1.2  and then use the
definitions above that explicitly define the 3 inputs.   TLS 1.3 defines
the PRF in terms of HKDF extract and expand functions from RFC 5869 so
there would need to be some mapping to 1.3 as well.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] Processing of TEWAP erratum 5127

[Joseph Salowey]

On Mon, Nov 25, 2019 at 5:43 AM Eliot Lear  wrote:

> Hi Juoni,
>
> Thanks for taking the time.  I suspect this will take a few iterations to
> get the actual text right, as I am drinking water from a fire hose here.
> Please bear with me.
>
> On 24 Nov 2019, at 12:31, Jouni Malinen  wrote:
>
> On Fri, Nov 22, 2019 at 05:21:10PM +0800, Eliot Lear wrote:
>
> I have been reviewing this erratum, and I think it is correct, but I have
> a question:
>
> Section 5.2. says:
>
> IMSK = First 32 octets of TLS-PRF(EMSK, "teapbind...@ietf.org" |
> "\0" | 64)
> It should say:
>
> IMSK = First 32 octets of TLS-PRF(EMSK, "teapbind...@ietf.org" |
> "\0", 64)
>
>
> Is that last parameter “seed” or “seed size”?  Confusedly yours.
>
>
> It's neither.. The main problem here is in RFC 7170 not defining
> TLS-PRF() properly. All it says is "TLS-PRF is the PRF negotiated as
> part of TLS handshake" while RFC 5246 does not define PRF as a function
> with arguments that would be compatible with even a single instance of
> TLS-PRF() use in RFC 7170..
>
>
>
[Joe] Looking at this again I do not think the errata is correct, but the
text is this section is confusing.

"If an inner method supports export of an Extended Master Session Key

   (EMSK), then the IMSK SHOULD be derived from the EMSK as defined in
   [RFC5295 ]. "


RFC5295 specifies the KDF signature


"USRK = KDF(EMSK, key label | "\0" | optional data | length)"


The IMSK adds confusion by substituting the TLS 1.2 PRF for the KDF. I
believe the intent here is to map this to the following in RFC5246


IMSK = First 32 octets of P_(EMSK, "teapbind...@ietf.org"| "\0"   |   64)


I don't think the errata text is correct.   It should either use the
existing text or the clarification using P_ form 5246 above.


The other key derivation in the spec are ambiguous as Jouni indicates,
but I need to give my brain a rest before I tackle those.





>
> And the RFC 7170 uses are inconsistent with
> themselves like this erratum show, but this instance is not the only
> issue: TLS-PRF() is used with two, three, and even four arguments.
>
>
>
> Indeed.  So that we’re clear, here they are:
>
> Section 5.2:
>  IMSK = First 32 octets of TLS-PRF(EMSK, "teapbind...@ietf.org" |
>  "\0" | 64)
>
>
> 2 args.
>
> Later, same section:
>
> IMCK[j] = TLS-PRF(S-IMCK[j-1], "Inner Methods Compound Keys",
> IMSK[j], 60)
>
> 4 args.
>
> And then further down:
>
>  MSK  = TLS-PRF(S-IMCK[j], "Session Key Generating Function", 64)
>  EMSK = TLS-PRF(S-IMCK[j],
>"Extended Session Key Generating Function", 64)
>
>
> 3 args.
>
>
> And 5246 says:
>
> PRF(secret, label, seed) = P_(secret, label + seed)
>
> And so I agree with you that nowhere is there a length field for the
> return value in RFC 5246.
>
>
> This
> leaves the implementer guessing what exactly these maps to..
>
> RFC5246 The Transport Layer Security (TLS) Protocol Version 1.2
> 5. HMAC and the Pseudorandom Function
> "TLS's PRF is created by applying P_hash to the secret as:
> PRF(secret, label, seed) = P_(secret, label + seed)"
>
>
> So this PRF(secret, label, seed) is what is available and RFC 5246 does
> not define that 64 part in the example above as an argument. That 64 is
> the number of octets of output that is fetched from the PRF.
>
> In other words, RFC 7170 should have defined TLS-PRF(secret, label,
> seed, output-len-in-octets) as taking output-len-in-octets of octets
> from the output of RFC 5246 PRF(secret, label, seed). With this,
> following fixes would be needed for the users for TLS-PRF() in RFC 7170:
>
> IMSK:
> This could be one of following (last two having identical outcome):
> TLS-PRF(EMSK, "teapbind...@ietf.org", "", 64)
> TLS-PRF(EMSK, "teapbind...@ietf.org", "\0", 64)
> TLS-PRF(EMSK, "teapbind...@ietf.org", "\0" | 0x00 | 0x40, 64)
> TLS-PRF(EMSK, "teapbind...@ietf.org", 0x00 | 0x00 | 0x40, 64)
>
> However, this TLS-PRF() instance is more strange.. The "Optional data
> parameter is not used in the derivation" part does not make any sense
> since I think "optional data parameter" is a reference to the seed value
> going into PRF.
>
>
>
> Could it be that this text refers to RFC 5295:
>
>  If an inner method supports export of an Extended Master Session Key
>  (EMSK), then the IMSK SHOULD be derived from the EMSK as defined in
>  [*RFC5295*].  The usage label used is "teapbind...@ietf.org", and the
>  length is 64 octets.  *Optional data parameter is not used in the*
> * derivation.*
>
>
> USRK = KDF(EMSK, key label | "\0" | optional data | length)
>
> Which perhaps is meant to translate to:
>
> IMSK = KDF(EMSK, “teapbind...@ietf.org”, 64)
>
> But again, only when the inner method supports export of the EMSK.  Note
> the text below, by the way:
>
> USRKs MUST be at least 64 octets in length.
>
>
>
> However we interpret the text, it seems that either the argument count is
> wrong or the function is wrong.
>
> The following description is then 

Re: [Emu] [lamps] EAP/EMU recommendations for client cert validation logic

[Joseph Salowey]

There has been a lot of discussion on this thread, but I do not see
anything actionable for the EAP-TLS 1.3 specification.

Joe

On Wed, Jan 8, 2020 at 12:48 PM Alan DeKok 
wrote:

> On Jan 8, 2020, at 3:00 PM, Michael Richardson 
> wrote:
> >
> >
> > Alan DeKok  wrote:
> >alan> Many people use private CAs.  Many use public CAs.  *All* of
> them
> >alan> use id-kp-serverAuth.  Common EAP supplicants (MS / Apple /
> etc.)
> >alan> ship with known root CAs.  These root CAs are trusted by default
> >alan> for web browsing.  None are trusted by default for EAP.
> >
> > How can anyone be using public CAs for EAP, if none are trusted for EAP,
> and no
> > public CAs issue certificates with id-kp-serverAuth?
>
>   Every CA is manually enabled.
>
>   Either by an end user, or by / on behalf of, an administrator.
>
>   The goal I'd like to reach is some method to allow supplicants to
> automatically trust and enable certificates for EAP.
>
>   Alan DeKok.
>
> ___
> Emu mailing list
> Emu@ietf.org
> https://www.ietf.org/mailman/listinfo/emu
>
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] AD review of draft-ietf-emu-rfc5448bis-06

[Joseph Salowey]

On Wed, Jan 15, 2020 at 2:24 PM Roman Danyliw  wrote:

> Hello!
>
> I conducted an AD review of draft-ietf-emu-rfc5448bis-06 and this document
> is in good shape.  Thanks for all of the work on it.  I have minor
> questions and editorial nits which can be addressed with the IETF Last Call
> feedback.
>
> Minor:
> -- Can you revisit the history -- why was RFC4187 informational?  I'm
> guessing this draft is informational because it updates RFC4187, right?
>
>
[Joe] From what I remember EAP-AKA and EAP-SIM were information because the
core authentication algorithms and protocols are defined and under the
control of 3GPP.  You can't implement this spec without those specs, which
may imply some intellectual property rights and restrictions.  The updates
to these documents have kept the informational status.



> -- Section 7.1.  Per "The use of pseudonyms in this situation is at best
> limited" - unclear to me what this means?  Is this say that pseudonyms is
> not recommended because the re-use is creates a tracking opportunity (per
> the next sentence)?
>
> -- Section 7.1.  Per "Outside 5G, there is a full choice to use ...", what
> is a "full choice"?
>
> Editorial Nits:
>
> -- Section 1.  s/EAP-AKA' is also an algorithm update for the used hash
> functions./EAP-AKA' also updates the algorithm used in the hash functions./
>
> -- Section 1.  s/The update ensures/This update ensures/
>
> -- Section 1.  Typo. s/how how/how/
>
> -- Section 3.5.  Consider giving the table an explicit number (e.g., Table
> 1) and s/The attribute table is shown below/The attribute table is shown in
> Table 1./
>
> -- Section 5.2.  s/However, to ensure privacy/However, to enhance privacy/
> -- there is no "absolute privacy".
>
> -- Section 5.2. s/for at attacker/for an attacker/
>
> -- Section 7.3.  s/an backwards/a backwards/
>
> Regards,
> Roman
>
> ___
> Emu mailing list
> Emu@ietf.org
> https://www.ietf.org/mailman/listinfo/emu
>
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

[Emu] Publication has been requested for draft-ietf-emu-rfc5448bis-06

[Joseph Salowey via Datatracker]

Joseph Salowey has requested publication of draft-ietf-emu-rfc5448bis-06 as 
Informational on behalf of the EMU working group.

Please verify the document's state at 
https://datatracker.ietf.org/doc/draft-ietf-emu-rfc5448bis/

___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

[Emu] Presentations for IETF 106

[Joseph Salowey]

If you are on the agenda [1] for IETF 106 in Singapore please send your
slides to emu-cha...@ietf.org as soon as possible as the meeting is on
Monday.  Failure to send your slides before the day of the meeting may
result in your presentation being pushed to the end of the agenda.

[1] (https://datatracker.ietf.org/meeting/106/materials/agenda-106-emu-00)
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] POST WGLC Comments draft-ietf-emu-eap-tls13

[Joseph Salowey]

On Mon, Nov 11, 2019 at 11:41 AM Alan DeKok 
wrote:

> On Nov 11, 2019, at 12:52 PM, Owen Friel (ofriel) 
> wrote:
> >
> > [ofriel]  Is the primary reason they MUST NOT be copied because of
> encoding differences? UTF-8 vs. TLS raw bytes?
>
>   Yes.  EAP Identities are UTF-8 encoded strings.  Non-compliant
> identities will likely result in the packet being dropped.
>
> > On the privacy aspect, as the TLS PSK ID is sent unprotected and
> unencrypted in cleartext in the ClientHello, what information leakage are
> we preventing by not sending that same data in cleartext in the Identity
> Response?
>
>   Not much.  Except that if we send the data in the Identity, it MUST be
> encoded in some format which is acceptable to EAP, RADIUS, etc.
>
>   Further, RFC 8446 says that PSK Identities can be be up to 2^16-1 octets
> in length.  While EAP can carry large identities, RADIUS cannot.  So we're
> left with a practical limitation of ~250 octets for the identity field.
>
>   At that point, it's best to recommend that the EAP Identity carry only
> an anonymous NAI.  That avoids the issue of PSK length and encoding
> entirely.  Further, it means that all uses of EAP-TLS have the same
> recommendation: the Identity is an anonymous NAI.
>
>
[Joe] I agree that its best to only include the anonymous NAI.  Including
more information may cause a problem if the PSK works changes in the future
or if you are copying the original NAI into subsequent transactions.


> > This is a different question to the difference between an extern PSK and
> a resumption PSK. That is implementation specific and not defined in TLS1.3
>
>   i.e. "good luck".  :(
>
>   It's difficult for implementors to do the right thing in such a
> situation.
>
> > [ofriel] I agree some implementation advice would be good here. Should
> this be in EAP, or should we push for a TLS1.3 errata? It's the same advice
> that a standard TLS1.3 server implementor needs. OpenSSL for example
> defines its own resumption format, and provides a callback hook to check
> for extern PSKs, and it looks like OpenSSL lets the application check for
> an extern PSK match first before checking its internal resumption cache:
> https://github.com/openssl/openssl/blob/master/ssl/statem/extensions_srvr.c#L1093.
> But of course that is TLS stack specific. We would need to document
> guidance olong the lines of checking for TLS stack behaviour.
>
>   I think it's best to give guidance in this document.
>
>
[Joe] If its needed then I also think we should include it in the EAP-TLS
document.  It wouldn't be bad to file an errata on TLS 1.3, but I think
this is more of a corner case for them.


>   Alan DeKok.
>
> ___
> Emu mailing list
> Emu@ietf.org
> https://www.ietf.org/mailman/listinfo/emu
>
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] POST WGLC Comments draft-ietf-emu-eap-tls13

[Joseph Salowey]

On Fri, Nov 1, 2019 at 4:08 AM Alan DeKok  wrote:

> On Nov 1, 2019, at 6:15 AM, John Mattsson 
> wrote:
> > I strongly support working group adoption of
> draft-dekok-emu-tls-eap-types. Can we make sure to get this document going,
> I agree that this is a very needed draft. I think it should include updates
> for everything people wants to use. I do not think draft-ietf-emu-eap-tls13
> strictly have to wait for draft-dekok-emu-tls-eap-types, but
> draft-dekok-emu-tls-eap-types should be published shortly after.
>
>   I will do an update to my document shortly.
>
>   I also added an issue with the EAP-TLS document on GitHub.  The
> suggestion is to add text which explains how (and why) the EAP Identity is
> chosen during resumption:
>
> ---
> The EAP Identity used in resumption SHOULD be the same EAP Identity as was
> used during the original authentication. This requirement allows EAP
> packets to be routable through an AAA infrastructure to the same
> destination as the original authentication.



>
>
The alternative is to derive the EAP Identity from the identity used inside
> of TLS. This derivation is common practice when using certificates, and
> works because the "common name" field in the certificate is typically
> compatible with EAP, and it contains a routable identifier such as an email
> address. This practice cannot be used for resumption, as the PSK identity
> may be a binary blob, and it might not contain a routable realm as
> suggested by RFC 7542.
>
>
[Joe] Do implementations use the whole common name or just the domain
portion.  Using the whole common name is not advisable with TLS 1.3.


> In some cases, the PSK identity is derived by the underlying TLS
> implementation, and cannot be controlled by the EAP authenticator. These
> limitations make the PSK identity unsuitable for use as the EAP Identity.
>

[Joe]  Is EAP Identity Synonymous with the NAI?


> ---
>
>   Alan DeKok.
>
>
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] POST WGLC Comments draft-ietf-emu-eap-tls13

[Joseph Salowey]

On Wed, Oct 30, 2019 at 4:12 AM Alan DeKok 
wrote:

> On Oct 30, 2019, at 5:02 AM, Eliot Lear  wrote:
> > A fair argument, if it can be made, and I am not convinced it has been
> fully expressed, is the idea that there is no context by which one can
> separate fast restart and initial authentication.  This is Alan’s concern.
> I’m not saying it’s without merit, but what I cannot yet see is whether it
> is an implementation or a protocol matter.
>
>   I believe it's a protocol matter.  In TLS 1.3, PSK handshakes are the
> same as resumption handshakes.
>
>   It's not clear to me how this issue was addressed when using TLS 1.3
> with HTTPS.  But I do believe it's an issue there, too.
>
>
[Joe] Can you elaborate on what the issue is?  I think most TLS deployments
operate in either a certificate based mode or a PSK mode, but not both at
the same time.


>   As an additional note, I believe it's also important that
> draft-dekok-emu-tls-eap-types be published at the same time as the EAP-TLS
> document.  The only unknown there is FAST and TEAP.  I'm happy to remove
> them from the document.
>
>   But at this point it's not even a WG document.  There's not even
> consensus that the document necessary, which surprises me rather a lot.
> Because password-based EAP methods are *much* more wide-spread than EAP-TLS.
>
>   If the IETF publishes EAP-TLS without simultaneously rev'ing TTLS and
> PEAP, it will not only look bad, it will *be* bad.  And the industry press
> will (rightfully) lambast the standards process.
>
>
[Joe] We need people to contribute to the document.  If we are going to
publish a document through the working group it needs to at least to
include TEAP.   I know there are folks on this list who are implementing.
They need to step up and help with this document and the TEAP errata.


>   Alan DeKok.
>
>
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] POST WGLC Comments draft-ietf-emu-eap-tls13

[Joseph Salowey]

Hi Jorge,

Thanks for joining the conversation.

On Wed, Oct 30, 2019 at 6:11 PM Jorge Vergara  wrote:

> Hello - I am the primary maintainer of Microsoft's EAP implementation. I
> am sorry for joining late to this conversation, but hope our input is
> welcome.
>
> On the topic of draft-dekok-emu-tls-eap-types:
>
> I agree that it is necessary to standardize other TLS based EAP methods at
> the same time as EAP-TLS. The alternatives if this doesn't happen were
> discussed here previously at
> https://mailarchive.ietf.org/arch/msg/emu/J9Afcza1gOBQ_jww8E0yxSKPYeo -
> namely, either implementations will forge ahead with non-standard updates
> anyways, or they will be forced to wait to update EAP-TLS until the other
> methods are updated.
>
> We are taking the second approach - we do not plan to update our EAP-TLS
> implementation until it is clear what the updates to other EAP methods will
> look like. We do not want to see non-standard vendor implementations to
> become difficult to implement de-facto standards. We would also like to see
> TEAP covered in this update.
>
> A brief review on the material contained in the
> draft-dekok-emu-tls-eap-types:
>
> I believe the 0x00 "Commitment message" not to send anymore TLS handshake
> data should be mentioned in this document, since it was established during
> https://mailarchive.ietf.org/arch/msg/emu/0MeocWZQLCv1pST5_2jW_ABlpMo
> that even tunnel based methods will need this.
>
> The key derivation proposed for TEAP/FAST uses the definition from FAST,
> which is not identical to the TEAP derivation. Namely, FAST used MSK[j] in
> the derivation, but TEAP uses IMSK[j], which may be equivalent in some
> cases, but may not in others where the inner method exports an EMSK. I
> understand there may be a TEAP errata related to this and I may not be
> fully up to date on the errata discussion, so perhaps this is already taken
> into consideration.
>
>
[Joe] I know that Alan has been asking for help with this draft especially
with TEAP and EAP-FAST.  I hope that you and others can work with him to
get the draft in a shape that we can progress through the working group.  I
agree that this is an important thing to do.

The EAP-TLS 1.3 draft is fairly far along and I do not think we have
consensus to add TEAP into the document at this point, but I think we can
make faster progress on the TLS types document if we have people interested
in working on it.


> Jorge Vergara
>
> -Original Message-
> From: Emu  On Behalf Of Alan DeKok
> Sent: Wednesday, October 30, 2019 4:12 AM
> To: Eliot Lear 
> Cc: draft-ietf-emu-eap-tl...@ietf.org; John Mattsson  40ericsson@dmarc.ietf.org>; Michael Richardson ;
> EMU WG 
> Subject: Re: [Emu] POST WGLC Comments draft-ietf-emu-eap-tls13
>
> On Oct 30, 2019, at 5:02 AM, Eliot Lear  wrote:
> > A fair argument, if it can be made, and I am not convinced it has been
> fully expressed, is the idea that there is no context by which one can
> separate fast restart and initial authentication.  This is Alan’s concern.
> I’m not saying it’s without merit, but what I cannot yet see is whether it
> is an implementation or a protocol matter.
>
>   I believe it's a protocol matter.  In TLS 1.3, PSK handshakes are the
> same as resumption handshakes.
>
>   It's not clear to me how this issue was addressed when using TLS 1.3
> with HTTPS.  But I do believe it's an issue there, too.
>
>   As an additional note, I believe it's also important that
> draft-dekok-emu-tls-eap-types be published at the same time as the EAP-TLS
> document.  The only unknown there is FAST and TEAP.  I'm happy to remove
> them from the document.
>
>   But at this point it's not even a WG document.  There's not even
> consensus that the document necessary, which surprises me rather a lot.
> Because password-based EAP methods are *much* more wide-spread than EAP-TLS.
>
>   If the IETF publishes EAP-TLS without simultaneously rev'ing TTLS and
> PEAP, it will not only look bad, it will *be* bad.  And the industry press
> will (rightfully) lambast the standards process.
>
>   Alan DeKok.
>
> ___
> Emu mailing list
> Emu@ietf.org
>
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Femudata=02%7C01%7Cjovergar%40microsoft.com%7C68e3a65a1c3441c857cb08d75d2a038b%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637080308161040037sdata=zrPr0rRh1bkV8rrF23SaAJYz6aFfuO3lTX9e6U1fOXw%3Dreserved=0
> ___
> Emu mailing list
> Emu@ietf.org
> https://www.ietf.org/mailman/listinfo/emu
>
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] POST WGLC Comments draft-ietf-emu-eap-tls13

[Joseph Salowey]

On Fri, Oct 11, 2019 at 7:34 AM Eliot Lear  wrote:

>
>
> > On 11 Oct 2019, at 16:09, Michael Richardson  wrote:
> >
> > So, can wired just be a degenerate version of wifi, where there can be
> only
> > one "ESSID", and there are no beacons to consider?
>
>
> On the whole that has been my thought.  But it is a matter of which
> mechanism to degenerate to.  Is it TLS-PSK?  eDPP++?  TLS with naked public
> keys++?  And again, this is the on-prem case.  For cloud, we are well along.
>

[Joe] We are currently in a holding pattern with EAP-TLS.  It does not seem
right to delay it for functionality that we are not sure we have a use case
for.  If a use case develops then we can publish an update to EAP-TLS 1.3.
Do we have a use case for EAP-TLS-PSK that is blocked in the current
situation?



> Eliot
>
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] TEAP errata 5770

[Joseph Salowey]

On Tue, Oct 8, 2019 at 10:46 PM Joseph Salowey  wrote:

> Based on Jouni's analysis the derivation of the S-IMCKs is not well
> specified.  To me it looks like the solution to handle an arbitrary number
> of methods that may or may not make an EMSK available would be fairly
> complex.
>
> I think the most straight forward solution is to either always assume that
> for an EMSK generating method the EMSK is either always available or always
> unavailable.  It seems that it is safer to always assume that the EMSK is
> unavailable and will therefore never be used.  I think this has the
> following implications:
>
> -  The S-IMCK is always generated from the inner method MSK or the
> all-zero value if the method does not generate key material.
> -  The EMSK compound MAC is not used
> -  Implementations must have a policy that accepts MSK MACs
>
> It would appear that from a cryptographic analysis point of view the MSK
> and EMSK are equivalent since these keys will only be used in these
> TEAP calculations and not for other purposes.  There are documented
> drawbacks of using the MSK described in RFC7029 (
> https://tools.ietf.org/html/rfc7029#page-12).   If the properties of the
> EMSK binding are needed in the use cases currently under consideration then
> I think we could redefine the way the EMSK MAC to be computed from the EMSK
> of the inner method changing the above to
>
> -  The S-IMCK is always generated from the inner method MSK or the
> all-zero value if the method does not generate key material.
> - Compute EMSK MAC from the inner-method EMSK instead of the S-IMCK
>  Compound-MAC = MAC( EMSK[J], BUFFER )
> -  Implementations have a policy that prevents EMSK downgrade to MSK
>
> Hopefully there is a more elegant solution. Any ideas?
>
>
[Joe] It might be better to do the following:

Singe S-IMCK chain, but when an EMSK method is used there are two pre
S-IMCK keys generated, one for the EMSK and one for the MSK.  These are
used to calculate two CMKs for Compound MACs for EMSK and MSK
respectively.  If the server responds with an EMSK MAC then the pre S-IMCK
generated from the EMSK is used as the S-IMCK for future calculations if
not then the one from the MSK is used.

Modification to section 5.2 Intermediate Compound Key Derivations:

When an EMSK generating method is used, then two compound MAC keys are
generated, one based on the IMSK with the EMSK from the current method and
on from the MSK from the current method as follows:

 S-IMCK[j-1] = compound session key from previous method:

 IMSK-EMSK[J] = First 32 octets of TLS-PRF(EMSK,
"teapbind...@ietf.org" | "\0" | 64)

 IMSK-MSK = MSK


 IMCK-EMSK[j] = TLS-PRF(S-IMCK[j-1], "Inner Methods Compound Keys",
IMSK-EMSK[j], 60)
   S-IMCK-EMSK[j] = first 40 octets of IMCK-EMSK[j]
   CMK-EMSK[j] = last 20 octets of IMCK-EMSK[j]


 IMCK-MSK[j] = TLS-PRF(S-IMCK[j-1], "Inner Methods Compound Keys",
IMSK-MSK[j], 60)
   S-IMCK-MSK[j] = first 40 octets of IMCK-EMSK[j]
   CMK-MSK[j] = last 20 octets of IMCK-EMSK[j]


  CMK-MSK[J] is used to calculate the MSK compound MAC

  CMK-EMSK[J] is used to calculate the EMSK compound MAC

If the EMSK MAC is returned form the server then the

 S-IMCK[j] = S-IMCK-EMSK[j]

else
  S-IMCK[j] = S-IMCK-MSK[j]

Modifications to  5.3.  Computing the Compound MAC

The Compound MAC EMSK computation is as follows:

  CMK-EMSK = CMK-EMSK[j]
  Compound-MAC-EMSK = MAC( CMK-EMSK, BUFFER )


The Compound MAC MSK computation is as follows:

  CMK-MSK = CMK-MSK[j]
  Compound-MAC-MSK = MAC( CMK-MSK, BUFFER )


I think this is more in line with what was originally intended and better
than what I originally wrote in the previous message.


> Joe
>
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

[Emu] TEAP errata 5770

[Joseph Salowey]

Based on Jouni's analysis the derivation of the S-IMCKs is not well
specified.  To me it looks like the solution to handle an arbitrary number
of methods that may or may not make an EMSK available would be fairly
complex.

I think the most straight forward solution is to either always assume that
for an EMSK generating method the EMSK is either always available or always
unavailable.  It seems that it is safer to always assume that the EMSK is
unavailable and will therefore never be used.  I think this has the
following implications:

-  The S-IMCK is always generated from the inner method MSK or the all-zero
value if the method does not generate key material.
-  The EMSK compound MAC is not used
-  Implementations must have a policy that accepts MSK MACs

It would appear that from a cryptographic analysis point of view the MSK
and EMSK are equivalent since these keys will only be used in these
TEAP calculations and not for other purposes.  There are documented
drawbacks of using the MSK described in RFC7029 (
https://tools.ietf.org/html/rfc7029#page-12).   If the properties of the
EMSK binding are needed in the use cases currently under consideration then
I think we could redefine the way the EMSK MAC to be computed from the EMSK
of the inner method changing the above to

-  The S-IMCK is always generated from the inner method MSK or the all-zero
value if the method does not generate key material.
- Compute EMSK MAC from the inner-method EMSK instead of the S-IMCK
 Compound-MAC = MAC( EMSK[J], BUFFER )
-  Implementations have a policy that prevents EMSK downgrade to MSK

Hopefully there is a more elegant solution. Any ideas?

Joe
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

[Emu] TEAP Errata 5768

[Joseph Salowey]

We need to come to resolution on how to resolve these errata.  I hope there
has been enough time for implementors to catch up with
Jouni's implementation.

The Crypto-Binding TLV is fixed at 20 octets and the draft does not say how
to handle longer MACs.

The discussion seems to indicate that we should make the TLV variable
length to handle longer MACs.

Is anyone else taking this approach with their implementation?

Is there any objection to move forward with making the MAC variable
length?

Cheers,

Joe
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] POST WGLC Comments draft-ietf-emu-eap-tls13

[Joseph Salowey]

There is a TLS working group draft on importing external PSKs for use with
TLS - https://tools.ietf.org/html/draft-ietf-tls-external-psk-importer-01.
This draft can mitigate some of the issues with using external PSKs.

My suggesting is to leave the draft as is and deal with external PSKs as an
update to EAP-TLS 1.3 or as a separate method.

Is the current published version up to date with the rest of the comments?

Thanks,

Joe

On Fri, Sep 20, 2019 at 3:42 AM John Mattsson  wrote:

> Hi Alan,
>
> I added references to RFC 8446 Section 8.1, and 8.2, and 4.2.11. Agree
> that they are good to point out.
>
> I am not sure about the other suggestions, I am hesitant to discuss
> anything detailed about TLS 1.3 that does not have a specific connection to
> EAP-TLS or are useful for users of EAP-TLS. My feeling is that adding some
> extension, but not other would be even more confusing. The diagrams are
> there to show the message flows, which have a strong connection to the EAP
> state machine. For other details I think implementors have to read RFC 8466.
>
> /John
>
> -Original Message-
> From: Alan DeKok 
> Date: Wednesday, 18 September 2019 at 15:21
> To: "draft-ietf-emu-eap-tl...@ietf.org" ,
> EMU WG 
> Subject: Re: [Emu] POST WGLC Comments draft-ietf-emu-eap-tls13
> Resent from: 
> Resent to: John Mattsson , 
> Resent date: Wednesday, 18 September 2019 at 15:21
>
>   Just re-reading the text on PSK, I noticed a few things.  The text
> in Section 2.1.2 talks about PSK, the session ticket, and a "key_share"
> extension.   The accompanying diagram doesn't include any of those.  I
> suggest updating the diagram to include them.
>
>   As a related note, if the PSK *is* in the resumption cache, but the
> key is wrong, the cache entry should not be discarded.  Otherwise an
> attacker can disable caching for *all* users.  This issue could be clearer
> in this document.
>
>   Perhaps it would be useful to add a short note in Section 5 about
> security of resumption.  It should reference RFC 8446 Section 8.1, and 8.2,
> which discuss this issue.  Also, Section 4.2.11 of that document has an
> "Implementor's note:" which is important.
>
>   Alan DeKok.
>
>
>
> ___
> Emu mailing list
> Emu@ietf.org
> https://www.ietf.org/mailman/listinfo/emu
>
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] Call for adoption of draft-dekok-emu-eap-session-id-01

[Joseph Salowey]

The for adoption has completed without any objection.  Please submit the
draft as draft-ietf-emu-eap-session-id.

Thanks,

Joe

On Wed, Jul 31, 2019 at 8:48 PM Joseph Salowey  wrote:

> This is a call for adoption for draft-dekok-emu-eap-session-id-01 as a EMU 
> working group item.  This draft had support at the working group meeting.  If 
> you object to adopting this work item please respond by August 12, 2019.
>
> Thanks,
>
> Joe
>
>
>
>
>
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] Call for adoption of draft-ms-emu-eaptlscert-03

[Joseph Salowey]

This call has completed with no objection.  Please submit the draft as draft
-ietf-emu-eaptlscert-00.

Thanks,

Joe

On Wed, Jul 24, 2019 at 12:47 PM Joseph Salowey  wrote:

> This is a call for adoption for draft-ms-emu-eaptlscert-03 as a EMU
> working group item.  This draft has had support from the WG for the past 2
> meeting.  If you object to this call for adoption please respond by August
> 6, 2019.
>
> Thanks,
>
> Joe
>
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

[Emu] Call for adoption of draft-dekok-emu-eap-session-id-01

[Joseph Salowey]

This is a call for adoption for draft-dekok-emu-eap-session-id-01 as a
EMU working group item.  This draft had support at the working group
meeting.  If you object to adopting this work item please respond by
August 12, 2019.

Thanks,

Joe
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] EAP-AKA' and Re: WG adoption call for draft-arkko-eap-aka-pfs

[Joseph Salowey]

Based on the responses on this thread and in the IETF 105 EMU meeting we
are going to accept this document as a working group item.

Cheers,

Joe

On Thu, Jun 27, 2019 at 1:55 PM Alan DeKok 
wrote:

> On Jun 27, 2019, at 12:51 PM, Joseph Salowey  wrote:
> >
> > Significant time has passed and no alternate proposals have surfaced.
> We need to decide whether to accept this document into the working group or
> not.  It seems that we have support for the view that working on this
> informational document in the working group is preferable to the
> independent submission track.
>
>   Yes.
>
> > Do working group members still have objections to taking this draft into
> the working group?   Please respond on this thread by July 5, 2019.
>
>   I have misgivings, but no objections.
>
>   Alan DeKok.
>
>
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

[Emu] Call for adoption of draft-ms-emu-eaptlscert-03

[Joseph Salowey]

This is a call for adoption for draft-ms-emu-eaptlscert-03 as a EMU working
group item.  This draft has had support from the WG for the past 2
meeting.  If you object to this call for adoption please respond by August
6, 2019.

Thanks,

Joe
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] RFC 7170 (TEAP) errata

[Joseph Salowey]

On Mon, Jul 1, 2019 at 4:11 PM Jouni Malinen  wrote:

> 
>
> (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
>
>
[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?



> 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
>
> ___
> Emu mailing list
> Emu@ietf.org
> https://www.ietf.org/mailman/listinfo/emu
>
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] RFC 7170 (TEAP) errata

[Joseph Salowey]

On Mon, Jul 1, 2019 at 4:11 PM Jouni Malinen  wrote:

> 
>
> (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
>
>
> [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
> Emu@ietf.org
> https://www.ietf.org/mailman/listinfo/emu
>
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

[Emu] EMU Agenda and presentations

[Joseph Salowey]

The agenda for the EMU meeting at IETF 105 has been posted (
https://datatracker.ietf.org/meeting/105/materials/agenda-105-emu).  We
have a pretty full schedule.  The chairs have the following asks of
presenters:

1. Slides for non-working group drafts should be sent to the chairs 48
hours before the meting and 24 hours in advance for working group drafts.

2. Every presentation should have a one-slide overview of the main points
with links to additional reading resources. Presentations should be able to
cover this slide in a few minutes. In cases where the WG runs short on time
due to critical working group discussions, such slides provide enough
information for interested readers to learn more.

3. Plan time for questions. This should typically be 25% or more of your
allotted time.

Thanks,

Mohit and Joe
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] [Technical Errata Reported] RFC7170 (5765)

[Joseph Salowey]

This report looks to be valid and straight forward.   Any objections to
verifying and accepting this errata report?

On Fri, Jun 28, 2019 at 1:16 AM RFC Errata System 
wrote:

> The following errata report has been submitted for RFC7170,
> "Tunnel Extensible Authentication Protocol (TEAP) Version 1".
>
> --
> You may review the report below and at:
> https://www.rfc-editor.org/errata/eid5765
>
> --
> Type: Technical
> Reported by: Jouni Malinen 
>
> Section: 4.2.2
>
> Original Text
> -
>M
>
>   Mandatory, set to one (1)
>
>
> Corrected Text
> --
>M
>
>   0 (Optional)
>
>
> Notes
> -
> Authority-ID TLV is used only as an Outer TLV (in TEAP/Start) and Section
> 4.3.1 mandates all Outer TLVs to be marked as optional ("Outer TLVs MUST be
> marked as optional"). As such, Section 4.2.2 is incorrect in claiming the
> Authority-ID TLV to use M=1.
>
> Instructions:
> -
> This erratum is currently posted as "Reported". If necessary, please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party
> can log in to change the status and edit the report, if necessary.
>
> --
> RFC7170 (draft-ietf-emu-eap-tunnel-method-10)
> --
> Title   : Tunnel Extensible Authentication Protocol (TEAP)
> Version 1
> Publication Date: May 2014
> Author(s)   : H. Zhou, N. Cam-Winget, J. Salowey, S. Hanna
> Category: PROPOSED STANDARD
> Source  : EAP Method Update
> Area: Security
> Stream  : IETF
> Verifying Party : IESG
>
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] EAP-AKA' and Re: WG adoption call for draft-arkko-eap-aka-pfs

[Joseph Salowey]

Significant time has passed and no alternate proposals have surfaced.  We
need to decide whether to accept this document into the working group or
not.  It seems that we have support for the view that working on this
informational document in the working group is preferable to the
independent submission track.

Do working group members still have objections to taking this draft into
the working group?   Please respond on this thread by July 5, 2019.

Thanks,

Joe

On Wed, Apr 3, 2019 at 4:59 AM Alan DeKok  wrote:

> On Apr 3, 2019, at 1:37 AM, Joseph Salowey  wrote:
> >
> > Thanks for reviving this thread.  I agree this is important work, but we
> need to have consensus to bring the item into the working group.  I think
> the IPR issue is the main sticking point.
> >
> > I'll note that RFC 5448 has a similar IPR declaration and both documents
> are targeted as informational.   Some possible ways forward:
> >
> > 1. Come up with an alternative proposal.  Since no one has already
> stepped forward I don't think this is realistic.
> > 2. Accept the document into the working group.
> > 3. Reject the document, which will force the work to go through the
> independent submission process, which will probably result in less broad
> and thorough review.
> > 4. Amendment to the license terms of the IPR - I have received no
> indication that this will happen
> >
> > The document will likely get published in either case 2 or 3 above.  I'd
> like to work through this discussion over the next few weeks so please
> voice your views on this thread.
>
>   Despite my misgivings, I think (2) is necessary here.
>
>   It would be helpful for the IETF as a whole to acknowledge the
> importance of Open Source in the IETF process.  And, that "RAND" licensing
> isn't necessarily RAND when fees are involved.
>
>   e.g. "Reasonable and Non-Discriminatory License to All Implementers with
> Possible Royalty/Fee"
>
>   OK, *what* is that fee?  A million dollars for a 5G operator / vendor?
> How much should an Open Source implementation pay?
>
>   Alan DeKok.
>
>
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

[Emu] WGLC completed for for draft-ietf-emu-eap-tls13-05

[Joseph Salowey]

The Working Group last call has completed with no comments for
draft-ietf-emu-eap-tls13-05.  I would like to confirm that some working
group members have reviewed the draft.  If you have reviewed the draft
please respond to this thread.

THanks,

Joe
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

[Emu] WGLC for draft-ietf-emu-eap-tls13-05

[Joseph Salowey]

This is the working group last call for "Unsing EAP-TLS with TLS 1.3" -
https://tools.ietf.org/html/draft-ietf-emu-eap-tls13-05.  Please review the
document and send your comments to the list by June 18, 2019.

Thanks,

Joe
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] EAP-AKA' and Re: WG adoption call for draft-arkko-eap-aka-pfs

[Joseph Salowey]

Thanks for reviving this thread.  I agree this is important work, but we
need to have consensus to bring the item into the working group.  I think
the IPR issue is the main sticking point.

I'll note that RFC 5448 has a similar IPR declaration and both documents
are targeted as informational.   Some possible ways forward:

1. Come up with an alternative proposal.  Since no one has already stepped
forward I don't think this is realistic.
2. Accept the document into the working group.
3. Reject the document, which will force the work to go through the
independent submission process, which will probably result in less broad
and thorough review.
4. Amendment to the license terms of the IPR - I have received no
indication that this will happen

The document will likely get published in either case 2 or 3 above.  I'd
like to work through this discussion over the next few weeks so please
voice your views on this thread.

Thanks,
Joe



On Sat, Mar 30, 2019 at 5:53 PM Michael Richardson 
wrote:

>
> Alan DeKok  wrote:
> >   Let's be realistic about the IETF.  While we pretend that we have
> > individual contributors, the reality is that large companies fund
> huge
> > chunks of it.  Those companies effectively shield individual
> > contributors from patent lawsuits.  i.e. no one will sue an employee
> of
> > Cisco about a standard, they will instead sue Cisco directly.
>
> Actually, nobody seems to sue the majors except other majors.
> Nobody seems to sue small entities that have no money except patent trolls.
>
> >   Michael and I have no such protection.  As an implementor of
> EAP-SIM
> > and EAP-AKA, he may be personally liable.  As the person hosting the
> > web site and source code, I may also be personally liable.
>
> I don't think you can be sued for patent infringemenet for writing about
> the patent, only for using it.Copyright, yes, but not patents.
>
> >   And realistically, Open Source has driven the explosion of tech
> > companies in the past 10 years.  I think few companies could have
> been
> > profitable if they had paid license fees for an OS, web server, etc.
> > So there should be a vested interest in protecting open source as
> part
> > of the IETF standardization process.
>
> I agree with you, and so it borders on seriously insulting to open source
> authors to have these super-vague IPR claims show up from non-technical
> lawyers.
>
> Let me restate my original opinion:
>- if this is important to 5G, then anything that gets in the way of
>  adoption is a problem.  If it's not important enough to fix the IPR,
>  then it's actually that important.
>- adopting AKA is very important.
>
>
> --
> ]   Never tell me the odds! | ipv6 mesh
> networks [
> ]   Michael Richardson, Sandelman Software Works| network
> architect  [
> ] m...@sandelman.ca  http://www.sandelman.ca/|   ruby on
> rails[
>
>
> ___
> Emu mailing list
> Emu@ietf.org
> https://www.ietf.org/mailman/listinfo/emu
>
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

[Emu] WGLC for RFC5448bis

[Joseph Salowey]

This is the working group last call for draft-ietf-emu-rfc5448bis-04
.  Please send
your comments to the list by 3/1/2019.

Thanks,

Joe and Mohit
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] WG adoption call for draft-arkko-eap-aka-pfs

[Joseph Salowey]

Please note there are IPR disclosure for draft-arkko-eap-aka-pfs-03.txt
<https://www.ietf.org/id/draft-arkko-eap-aka-pfs-03.txt> available at
https://datatracker.ietf.org/ipr/search/?submit=draft=draft-arkko-eap-aka-pfs
..

Thanks,

Joe

On Thu, Nov 8, 2018 at 10:13 AM Joseph Salowey  wrote:

> At the IETF 103 meeting there was support in the room to adopt
> draft-arkko-eap-aka-pfs-03.txt as a working group item as the basis to add
> perfect forward secrecy to EAP-AKA.  This message is to confirm that
> consensus.  If you do not support adoption of
> draft-arkko-eap-aka-pfs-03.txt as WG item please say so by 2359UTC on 30
> November 2018 (and say why).
>
> The draft is available at
> https://www.ietf.org/id/draft-arkko-eap-aka-pfs-03.txt.
>
> Thanks,
>
> Joe
>
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

[Emu] WGLC for draft-ietf-emu-rfc5448bis

[Joseph Salowey]

This is the working group last call for the draft revision of "Improved
Extensible Authentication Protocol Method for 3rd Generation Authentication
and Key Agreement (EAP-AKA')" available at
https://datatracker.ietf.org/doc/draft-ietf-emu-rfc5448bis/

Please review the document and send your comments to the list by 2359
UTC on 30 November 2018.

Thanks,

Mohit and Joe
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

[Emu] WG adoption call for draft-arkko-eap-aka-pfs

[Joseph Salowey]

At the IETF 103 meeting there was support in the room to adopt
draft-arkko-eap-aka-pfs-03.txt as a working group item as the basis to add
perfect forward secrecy to EAP-AKA.  This message is to confirm that
consensus.  If you do not support adoption of
draft-arkko-eap-aka-pfs-03.txt as WG item please say so by 2359UTC on 30
November 2018 (and say why).

The draft is available at
https://www.ietf.org/id/draft-arkko-eap-aka-pfs-03.txt.

Thanks,

Joe
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

[Emu] Slides for the meeting

[Joseph Salowey]

If you are going to present at the meeting on Friday please send me your
slides.

Thanks,

Joe
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu