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

2019-10-30 Thread 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

2019-10-30 Thread 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

2019-10-30 Thread Jorge Vergara
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.

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


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

2019-10-30 Thread Alan DeKok
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://www.ietf.org/mailman/listinfo/emu


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

2019-10-30 Thread Eliot Lear


> On 30 Oct 2019, at 06:22, Joseph Salowey  wrote:
> 
> 
> 
> 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?
> 

I would suggest that we do have a well-identified use case, although it has 
some issues, and that is IoT onboarding for on-prem equipment, as Owen 
described.  I do not know if we will end up executing on that use case, but it 
is a use case.  On the whole, the argument has to go the other way: why should 
we cripple a particular TLS method without strong justification?  The more we 
specialize the longer it takes to deliver new services, and the harder they are 
to support.

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.

Eliot

> 
> 
> Eliot



signature.asc
Description: Message signed with OpenPGP
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu