Hi John, I understand your concern of EAP restricting TLS authentication methods. However, it is not unusual for other groups to define profiles of a protocol they rely on.
If someone's IoT device wants only EAP-TLS-PSK and nothing else, then I believe we should enable that. I agree with you that a separate document and type code for each TLS authentication method is not ideal either. We could do something like EAP-TLS-FULL as you suggest (as long as developers can pick and choose only relevant TLS authentication method). Also, we are not yet running out of the type code (and expanded type code) space for now. If others are interested in defining some EAP-TLS-foo method later on, they have the liberty to do that. --Mohit On 3/11/20 10:01 AM, John Mattsson wrote: > Hi, > > Russ Housley wrote: > >> I do not understand the reason for Bernard's objection. I looked at the > minutes, and I do not find any rationale there. Can you help? > > If I remember correctly, Bernard stated that the indroduction of PSK could > weaken the implementation and violate the security proofs of EAP-TLS. I don't > really agree with Bernard, but I am fine with resticting the type code 0x0D > to certificates only. I am not sure any proofs with TLS 1.1 would apply to > TLS 1.3 anyway as TLS 1.3 is basically a new protocol, reusing encoding and > IANA registers from the old version. > > Given that the EAP-TLS Type-Code 0x0D is decicated to Certificates, I am not > sure the approach to dedicate a new type code for PSK authentication is the > correct choice. > > psk_ke > psk_dhe_ke > tls_cert_with_extern_psk+psk_dhe_ke > > are just three of many authentication methods that may not fit in type code > 0x0D. Earlier versions of TLS have supported many more authentication methods > > KRB5 > anon > SRP > ECCPWD > > And just looking at the TLS WG documents, there are several future > authentication methods for TLS 1.3 likely in the future. > > https://datatracker.ietf.org/doc/draft-wang-tls-raw-public-key-with-ibc/ > https://datatracker.ietf.org/doc/draft-tschofenig-tls-cwt/ > https://datatracker.ietf.org/doc/draft-vanrein-tls-kdh/ > > I do not think the EAP group should forbid any TLS 1.3 authentication method > unless there is valid reasons to do so. Instead of the current suggestion: > > 0x0D EAP-TLS (cert and nothing else) > 0xTBD EAP-TLS-PSK (psk and psk+something else) > > I think a better way to structure things would be: > > 0x0D EAP-TLS (cert and nothing else) > 0xTBD EAP-TLS-FULL (everything that TLS 1.3 supports) > > I sympatise with earlier comments in the group that EAP should mostly be a > transport for TLS and that the decisions of which authentication methods to > support should be taken by the TLS WG. > > Cheers, > John > > -----Original Message----- > From: Russ Housley <hous...@vigilsec.com> > Date: Tuesday, 10 March 2020 at 18:48 > To: Mohit Sethi M <mohit.m.se...@ericsson.com> > Cc: John Mattsson <john.matts...@ericsson.com>, EMU WG <emu@ietf.org> > Subject: Re: [Emu] Late WGLC Comment on draft-ietf-emu-eap-tls13 > > Thanks for the pointer. > > I am fine with the proposed way forward. > > Russ > > > > On Mar 10, 2020, at 12:43 PM, Mohit Sethi M > <mohit.m.se...@ericsson.com> wrote: > > > > Hi Russ, > > > > You can listen here: https://youtu.be/YJLG4JUftqI?t=1144 > > > > We plan to support it in EAP-TLS-PSK instead: > > https://tools.ietf.org/html/draft-mattsson-emu-eap-tls-psk-00. We have > > already added a reference to draft-ietf-tls-tls13-cert-with-extern-psk > > and plan to use it. I think using an external PSK any ways requires > > ironing out some issues like what is the relationship between NAI and > > the PSK identity? And do we allow user-configured PSK identities/PSKs > etc.? > > > > Would it be reasonable if we specify the usage of > > draft-ietf-tls-tls13-cert-with-extern-psk in EAP-TLS-PSK instead? > > > > --Mohit > > > > On 3/10/20 6:30 PM, Russ Housley wrote: > >> I do not understand the reason for Bernard's objection. I looked at > the minutes, and I do not find any rationale there. Can you help? > >> > >> Russ > >> > >> > >>> On Mar 9, 2020, at 5:59 AM, John Mattsson > <john.matts...@ericsson.com> wrote: > >>> > >>> Hi Russ, > >>> > >>> Sorry for the late reply. I actually brought up your draft > [ID-ietf-tls-tls13-cert-with-extern-psk] during my EMU presentation at IETF > 106 as something that should probably be in EAP-TLS. Bernard Aboba then > expressed a very strong opinion that [ID-ietf-tls-tls13-cert-with-extern-psk] > should absolutely not be included in the EAP-TLS Type-Code 0x0D. After this > the WG decided as a way forward to specify EAP-TLS with PSK authentication in > a new draft. > >>> > >>> Given these strong opinions from Bernard Aboba, and the wish to > publish draft-ietf-emu-eap-tls13 soon. I think the best way forward would be > specify the use of [ID-ietf-tls-tls13-cert-with-extern-psk] in the same new > draft as EAP-TLS with PSK authentication. Does that sound like an acceptable > way forward? > >>> > >>> Cheers, > >>> John > >>> > >>> -----Original Message----- > >>> From: Russ Housley <hous...@vigilsec.com> > >>> Date: Monday, 13 January 2020 at 18:29 > >>> To: John Mattsson <john.matts...@ericsson.com> > >>> Cc: EMU WG <emu@ietf.org> > >>> Subject: Late WGLC Comment on draft-ietf-emu-eap-tls13 > >>> > >>> John: > >>> > >>> Section 2.1.1 says: > >>> > >>> Pre-Shared Key (PSK) authentication SHALL NOT be used except > >>> for resumption. > >>> > >>> I would rather this say: > >>> > >>> Pre-Shared Key (PSK) authentication SHALL NOT be used except > >>> for resumption or in conjunction with the > "tls_cert_with_extern_psk" > >>> extension [ID-ietf-tls-tls13-cert-with-extern-psk]. > >>> > >>> Russ > >>> > >>> > >>> > >> _______________________________________________ > >> 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
