Re: [Emu] [EXTERNAL] Re: More TEAP issues

[Eliot Lear]

No, but I would ask that we still have an interim to close the errata.

Eliot

On 01.12.22 06:22, Joseph Salowey wrote:
It sounds like we are gaining consensus to create a revision of TEAP.  
The emphasis would be (in priority order):


  * Aligning specification with current implementations
  * Clarifying the existing specification
  * Adding missing TLVs to make existing use cases work better

The goal is to get this revision done quickly to prevent further 
implementation divergence.  Changes will need to go through the 
working group process. Errata should be addressed when 
relevant portions of the document are updated.


Does anyone object to this approach?

Thanks,

Joe and Peter

On Wed, Nov 30, 2022 at 12:48 PM Bruno Pereira Vidal 
 wrote:


I also think option 3 is the preferred one at this point, given
the interoperable implementations that have already shipped. In
addition to Cisco ISE, the Windows TEAP implementation has also
been validated against Aruba ClearPass.

The person who implemented the Windows client code is no longer at
Microsoft and, unfortunately, I don't recall why this ended up
being implemented like this. It is likely that it was
inadvertently inherited from EAP-FAST as mentioned below.

Thanks,
Bruno

-Original Message-
From: Emu  On Behalf Of Jouni Malinen
Sent: Wednesday, November 30, 2022 10:33 AM
To: Alexander Clouter mailto:alex%2bi...@coremem.com>>
Cc: EMU WG 
Subject: [EXTERNAL] Re: [Emu] More TEAP issues

On Wed, Nov 30, 2022 at 03:01:08PM +, Alexander Clouter wrote:
> On Tue, 29 Nov 2022, at 22:34, Alan DeKok wrote:
> > Based on interoperability testing, it looks like implementations
> > followed EAP-FAST for derivation of the MS-MPPE keys, and not
RFC 7170:

> EAP-FAST almost does not document this until you look at a
latter RFC covering the provisioning component:
>
>
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> rfc-editor.org

%2Frfc%2Frfc5422%23section-3.2.3&data=05%7C01%7CBruno.Vi
> dal%40microsoft.com
%7C0e1894aabf524f8c70d708dad30154ed%7C72f988bf86f14
>
1af91ab2d7cd011db47%7C1%7C0%7C638054299953760498%7CUnknown%7CTWFpbGZsb
>
3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%
>
7C3000%7C%7C%7C&sdata=PqpDLwSPz0sh%2BsSlXadTZCAWI2835mdqgZvR2jN1Vgw%3D
> &reserved=0

And that section has a history of its own.. If you take a look at
the latest draft (-10), that language is not there, i.e., it got
added quite late in the process and the related discussions were
not exactly considering this positively. If I remember correctly,
this mismatch with how EAP-MSCHAPv2 was defined was seen as
something that should not really have been done and the
EAP-FAST-MSCHAPv2 was named such to be distinguished from
EAP-MSCHAPv2 and also as a reminder not to use this variant for
anything else than EAP-FAST (which had already been deployed with
it). Nevertheless, here we are 15 years later hitting this exact
same thing with TEAP having been deployed with the design that was
not supposed to be repeated..

> Really easy to miss for an implementer, especially as when you
start implementing FAST (or TEAP) you begin with authentication
and think you can ignore the PAC component at first.

While I started working on TEAP implementation by copying FAST
implementation to be the starting point, one of my first steps was
to try to remove all the hacks needed to get EAP-FAST
interoperable since I was familiar with the history.. But yes, it
would be next to impossible to implement either EAP-FAST or
EAP-TEAP based on just the RFCs and get to something that
interoperates with anything already deployed.

> The other biggy is that it is easy to miss that for each EAP
method in a sequence, you need to include an EAP Identity response
along with the Identity-Type TLV to the peer.

And that will hopefully not include another instance of
Crypto-Binding for the EAP-Identity exchange. This is related to
one of my errata comments on EAP method vs. EAP authentication
method (the latter needs crypto binding; the former probably does
not, but RFC 7170 is not clear).

> > 3) declare 7170  irretrievably broken, and write 7170bis which
> > documents how TEAP version 1 operates in practice.
>
> This is my preference too.

While this might not result in the cleanest protocol design, I'd
agree that this is likely the best approach from the view point of
getting something useful out there and into wider use.


Regarding a separate comment about new TLVs (and new functionality
in general, I'd guess), I have no significant issues including
that in a new RFC, but I do hope that the initial focus would be
in add

Re: [Emu] [EXTERNAL] Re: More TEAP issues

[Joseph Salowey]

It sounds like we are gaining consensus to create a revision of TEAP.  The
emphasis would be (in priority order):

   - Aligning specification with current implementations
   - Clarifying the existing specification
   - Adding missing TLVs to make existing use cases work better

The goal is to get this revision done quickly to prevent further
implementation divergence.  Changes will need to go through the working
group process. Errata should be addressed when relevant portions of the
document are updated.

Does anyone object to this approach?

Thanks,

Joe and Peter

On Wed, Nov 30, 2022 at 12:48 PM Bruno Pereira Vidal  wrote:

> I also think option 3 is the preferred one at this point, given the
> interoperable implementations that have already shipped. In addition to
> Cisco ISE, the Windows TEAP implementation has also been validated against
> Aruba ClearPass.
>
> The person who implemented the Windows client code is no longer at
> Microsoft and, unfortunately, I don't recall why this ended up being
> implemented like this. It is likely that it was inadvertently inherited
> from EAP-FAST as mentioned below.
>
> Thanks,
> Bruno
>
> -Original Message-
> From: Emu  On Behalf Of Jouni Malinen
> Sent: Wednesday, November 30, 2022 10:33 AM
> To: Alexander Clouter 
> Cc: EMU WG 
> Subject: [EXTERNAL] Re: [Emu] More TEAP issues
>
> On Wed, Nov 30, 2022 at 03:01:08PM +, Alexander Clouter wrote:
> > On Tue, 29 Nov 2022, at 22:34, Alan DeKok wrote:
> > > Based on interoperability testing, it looks like implementations
> > > followed EAP-FAST for derivation of the MS-MPPE keys, and not RFC 7170:
>
> > EAP-FAST almost does not document this until you look at a latter RFC
> covering the provisioning component:
> >
> > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> > rfc-editor.org%2Frfc%2Frfc5422%23section-3.2.3&data=05%7C01%7CBruno.Vi
> > dal%40microsoft.com%7C0e1894aabf524f8c70d708dad30154ed%7C72f988bf86f14
> > 1af91ab2d7cd011db47%7C1%7C0%7C638054299953760498%7CUnknown%7CTWFpbGZsb
> > 3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%
> > 7C3000%7C%7C%7C&sdata=PqpDLwSPz0sh%2BsSlXadTZCAWI2835mdqgZvR2jN1Vgw%3D
> > &reserved=0
>
> And that section has a history of its own.. If you take a look at the
> latest draft (-10), that language is not there, i.e., it got added quite
> late in the process and the related discussions were not exactly
> considering this positively. If I remember correctly, this mismatch with
> how EAP-MSCHAPv2 was defined was seen as something that should not really
> have been done and the EAP-FAST-MSCHAPv2 was named such to be distinguished
> from EAP-MSCHAPv2 and also as a reminder not to use this variant for
> anything else than EAP-FAST (which had already been deployed with it).
> Nevertheless, here we are 15 years later hitting this exact same thing with
> TEAP having been deployed with the design that was not supposed to be
> repeated..
>
> > Really easy to miss for an implementer, especially as when you start
> implementing FAST (or TEAP) you begin with authentication and think you can
> ignore the PAC component at first.
>
> While I started working on TEAP implementation by copying FAST
> implementation to be the starting point, one of my first steps was to try
> to remove all the hacks needed to get EAP-FAST interoperable since I was
> familiar with the history.. But yes, it would be next to impossible to
> implement either EAP-FAST or EAP-TEAP based on just the RFCs and get to
> something that interoperates with anything already deployed.
>
> > The other biggy is that it is easy to miss that for each EAP method in a
> sequence, you need to include an EAP Identity response along with the
> Identity-Type TLV to the peer.
>
> And that will hopefully not include another instance of Crypto-Binding for
> the EAP-Identity exchange. This is related to one of my errata comments on
> EAP method vs. EAP authentication method (the latter needs crypto binding;
> the former probably does not, but RFC 7170 is not clear).
>
> > > 3) declare 7170  irretrievably broken, and write 7170bis which
> > > documents how TEAP version 1 operates in practice.
> >
> > This is my preference too.
>
> While this might not result in the cleanest protocol design, I'd agree
> that this is likely the best approach from the view point of getting
> something useful out there and into wider use.
>
>
> Regarding a separate comment about new TLVs (and new functionality in
> general, I'd guess), I have no significant issues including that in a new
> RFC, but I do hope that the initial focus would be in addressing the
> existing areas and already identified issues to get to a point where there
> is a clearly identifiable Internet-Draft describing how one can
> successfully implement EAP-TEAP in a manner that interoperates with
> deployed implementations.
>
> --
> Jouni MalinenPGP id EFC895FA
>
> _

[Emu] Minutes from IETF 115 are available

[Peter Yee]

The minutes from the IETF 115 EMU session have been published at
https://datatracker.ietf.org/meeting/115/materials/minutes-115-emu-202211071
530-00.

 

Thanks so much to Janfred Rieckers for the in-meeting notetaking. It's
greatly appreciated and crucial to a successful meeting.

 

Cheers,

Peter and Joe

 

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

Re: [Emu] [EXTERNAL] Re: More TEAP issues

[Bruno Pereira Vidal]

I also think option 3 is the preferred one at this point, given the 
interoperable implementations that have already shipped. In addition to Cisco 
ISE, the Windows TEAP implementation has also been validated against Aruba 
ClearPass.

The person who implemented the Windows client code is no longer at Microsoft 
and, unfortunately, I don't recall why this ended up being implemented like 
this. It is likely that it was inadvertently inherited from EAP-FAST as 
mentioned below.

Thanks,
Bruno

-Original Message-
From: Emu  On Behalf Of Jouni Malinen
Sent: Wednesday, November 30, 2022 10:33 AM
To: Alexander Clouter 
Cc: EMU WG 
Subject: [EXTERNAL] Re: [Emu] More TEAP issues

On Wed, Nov 30, 2022 at 03:01:08PM +, Alexander Clouter wrote:
> On Tue, 29 Nov 2022, at 22:34, Alan DeKok wrote:
> > Based on interoperability testing, it looks like implementations 
> > followed EAP-FAST for derivation of the MS-MPPE keys, and not RFC 7170:

> EAP-FAST almost does not document this until you look at a latter RFC 
> covering the provisioning component:
> 
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> rfc-editor.org%2Frfc%2Frfc5422%23section-3.2.3&data=05%7C01%7CBruno.Vi
> dal%40microsoft.com%7C0e1894aabf524f8c70d708dad30154ed%7C72f988bf86f14
> 1af91ab2d7cd011db47%7C1%7C0%7C638054299953760498%7CUnknown%7CTWFpbGZsb
> 3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%
> 7C3000%7C%7C%7C&sdata=PqpDLwSPz0sh%2BsSlXadTZCAWI2835mdqgZvR2jN1Vgw%3D
> &reserved=0

And that section has a history of its own.. If you take a look at the latest 
draft (-10), that language is not there, i.e., it got added quite late in the 
process and the related discussions were not exactly considering this 
positively. If I remember correctly, this mismatch with how EAP-MSCHAPv2 was 
defined was seen as something that should not really have been done and the 
EAP-FAST-MSCHAPv2 was named such to be distinguished from EAP-MSCHAPv2 and also 
as a reminder not to use this variant for anything else than EAP-FAST (which 
had already been deployed with it). Nevertheless, here we are 15 years later 
hitting this exact same thing with TEAP having been deployed with the design 
that was not supposed to be repeated..

> Really easy to miss for an implementer, especially as when you start 
> implementing FAST (or TEAP) you begin with authentication and think you can 
> ignore the PAC component at first.

While I started working on TEAP implementation by copying FAST implementation 
to be the starting point, one of my first steps was to try to remove all the 
hacks needed to get EAP-FAST interoperable since I was familiar with the 
history.. But yes, it would be next to impossible to implement either EAP-FAST 
or EAP-TEAP based on just the RFCs and get to something that interoperates with 
anything already deployed.

> The other biggy is that it is easy to miss that for each EAP method in a 
> sequence, you need to include an EAP Identity response along with the 
> Identity-Type TLV to the peer.

And that will hopefully not include another instance of Crypto-Binding for the 
EAP-Identity exchange. This is related to one of my errata comments on EAP 
method vs. EAP authentication method (the latter needs crypto binding; the 
former probably does not, but RFC 7170 is not clear).

> > 3) declare 7170  irretrievably broken, and write 7170bis which 
> > documents how TEAP version 1 operates in practice.
> 
> This is my preference too.

While this might not result in the cleanest protocol design, I'd agree that 
this is likely the best approach from the view point of getting something 
useful out there and into wider use.


Regarding a separate comment about new TLVs (and new functionality in general, 
I'd guess), I have no significant issues including that in a new RFC, but I do 
hope that the initial focus would be in addressing the existing areas and 
already identified issues to get to a point where there is a clearly 
identifiable Internet-Draft describing how one can successfully implement 
EAP-TEAP in a manner that interoperates with deployed implementations.

-- 
Jouni MalinenPGP id EFC895FA

___
Emu mailing list
Emu@ietf.org
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Femu&data=05%7C01%7CBruno.Vidal%40microsoft.com%7C0e1894aabf524f8c70d708dad30154ed%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638054299953760498%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=pz4lgBHc0Y37IWf6EJ5Dr%2BaR7COUYesNVhomKHmNrIs%3D&reserved=0

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

Re: [Emu] More TEAP issues

[Jouni Malinen]

On Wed, Nov 30, 2022 at 03:01:08PM +, Alexander Clouter wrote:
> On Tue, 29 Nov 2022, at 22:34, Alan DeKok wrote:
> > Based on interoperability testing, it looks like implementations 
> > followed EAP-FAST for derivation of the MS-MPPE keys, and not RFC 7170:

> EAP-FAST almost does not document this until you look at a latter RFC 
> covering the provisioning component:
> 
> https://www.rfc-editor.org/rfc/rfc5422#section-3.2.3

And that section has a history of its own.. If you take a look at the
latest draft (-10), that language is not there, i.e., it got added quite
late in the process and the related discussions were not exactly
considering this positively. If I remember correctly, this mismatch with
how EAP-MSCHAPv2 was defined was seen as something that should not
really have been done and the EAP-FAST-MSCHAPv2 was named such to be
distinguished from EAP-MSCHAPv2 and also as a reminder not to use this
variant for anything else than EAP-FAST (which had already been deployed
with it). Nevertheless, here we are 15 years later hitting this exact
same thing with TEAP having been deployed with the design that was not
supposed to be repeated..

> Really easy to miss for an implementer, especially as when you start 
> implementing FAST (or TEAP) you begin with authentication and think you can 
> ignore the PAC component at first.

While I started working on TEAP implementation by copying FAST
implementation to be the starting point, one of my first steps was to
try to remove all the hacks needed to get EAP-FAST interoperable since I
was familiar with the history.. But yes, it would be next to impossible
to implement either EAP-FAST or EAP-TEAP based on just the RFCs and get
to something that interoperates with anything already deployed.

> The other biggy is that it is easy to miss that for each EAP method in a 
> sequence, you need to include an EAP Identity response along with the 
> Identity-Type TLV to the peer.

And that will hopefully not include another instance of Crypto-Binding
for the EAP-Identity exchange. This is related to one of my errata
comments on EAP method vs. EAP authentication method (the latter needs
crypto binding; the former probably does not, but RFC 7170 is not
clear).

> > 3) declare 7170  irretrievably broken, and write 7170bis which 
> > documents how TEAP version 1 operates in practice.
> 
> This is my preference too.

While this might not result in the cleanest protocol design, I'd agree
that this is likely the best approach from the view point of getting
something useful out there and into wider use.


Regarding a separate comment about new TLVs (and new functionality in
general, I'd guess), I have no significant issues including that in a
new RFC, but I do hope that the initial focus would be in addressing the
existing areas and already identified issues to get to a point where
there is a clearly identifiable Internet-Draft describing how one can
successfully implement EAP-TEAP in a manner that interoperates with
deployed implementations.

-- 
Jouni MalinenPGP id EFC895FA

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

Re: [Emu] More TEAP issues

[Alexander Clouter]

Hello,

On Tue, 29 Nov 2022, at 22:34, Alan DeKok wrote:
> Based on interoperability testing, it looks like implementations 
> followed EAP-FAST for derivation of the MS-MPPE keys, and not RFC 7170:
>
> http://lists.infradead.org/pipermail/hostap/2022-July/040639.html
>
> http://lists.infradead.org/pipermail/hostap/2022-November/041060.html

EAP-FAST almost does not document this until you look at a latter RFC covering 
the provisioning component:

https://www.rfc-editor.org/rfc/rfc5422#section-3.2.3

Really easy to miss for an implementer, especially as when you start 
implementing FAST (or TEAP) you begin with authentication and think you can 
ignore the PAC component at first.

I suspect Microsoft and Cisco just cut'n'pasted from their FAST implementation 
and used it whilst implementing TEAP and never looked back. It worked as they 
may have both done this.

The other biggy is that it is easy to miss that for each EAP method in a 
sequence, you need to include an EAP Identity response along with the 
Identity-Type TLV to the peer.

Windows 10/11 wonderfully from their UI configure (as labelled) 'first' and 
'second' method, but after completing the first if the server does not ask for 
the identity of the second, Windows will return a zero length identity and then 
refuse to go any further; well I was unable to persuade it.

Once you figure this out, it sort of makes sense (thinking of how a peer may 
have chosen to implement its state machine and that as a server you may want to 
proxy a given method) but EAP sequences themselves are not really well defined.

EAP (https://www.rfc-editor.org/rfc/rfc3748#section-2.1) only covers that 
outside a tunnel this is not supported.

FAST (https://www.rfc-editor.org/rfc/rfc4851#section-3.3.1) and TEAP 
(https://www.rfc-editor.org/rfc/rfc7170.html#section-3.3.1) states why they are 
allowed to use sequences and only because of Intermediate-Result/Crypto-Binding 
TLVs.

I have not yet found anything that provides guidance on how to actually do an 
EAP sequence.

FAST (https://www.rfc-editor.org/rfc/rfc4851#appendix-A.6) does not state you 
need to send a EAP Identity at the start of each method other than for the 
first one. I do not know if this is accurate as we never implemented for 
FreeRADIUS sequences for FAST.

TEAP (https://www.rfc-editor.org/rfc/rfc7170.html#appendix-C.6) also does not, 
but I know from the FreeRADIUS implementation it was needed to get sequences to 
work.

It took this implementer quite a while to realise that each EAP method in a 
sequence stands alone to the others and needs to be initiated with an 
EAP-Identity response.

> 3) declare 7170  irretrievably broken, and write 7170bis which 
> documents how TEAP version 1 operates in practice.

This is my preference too.

Whilst this is all in my head, having just done the 
FreeRADIUS/hostapd/Win10/Win11 interop work, I willing to kick off process by 
updating the existing RFC.

Fortunately during my work I also submitted fixes to Wireshark so since 4.0 you 
get TEAP decoding and inner EAP-TLS decryption so this allows us to share PCAPs 
of this in the wild. Hopefully with that people here can use it to fix up my 
notes to remove any further ambiguity if that sounds useful to others?

Thanks

Alex

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

Re: [Emu] More TEAP issues

[Alan DeKok]

On Nov 30, 2022, at 1:24 AM, Eliot Lear  wrote:
> I'd also like to take some time to consider what additional TLVs may be 
> required.  Right now there is an incongruence between TEAP and other 
> protocols that sign certs in that there is no CSR attributes TLV.  There may 
> be several others to consider.

  While I'm wary of extending the scope of a "fix errata" -bis document, 
"making it work" is also a high priority.

  So, yes.  Adding more TLVs is fine.  Current implementations don't use them, 
but they could be updated without affecting interoperability.

  Alan DeKok.

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