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

2019-09-18 Thread Alan DeKok
On Sep 18, 2019, at 5:42 PM, Owen Friel (ofriel)  wrote:
> Giving some implementation guidance seems appropriate here. Naively, one 
> could envisage the implementation simply having a DB table for extern PSKs 
> and a table that holds NewSessionTickets. An implementation could simply 
> check the extern PSK table using the PskIdentity.identity, and if no match is 
> found then check the NewSessionTickets table.

  Which works, but should be called out in the draft.

  And what is to prevent the system from generating conflicting PSK identities? 
 i.e. I don't control OpenSSL.  From what I see, TLS 1.3 resumption means that 
OpenSSLL will choose whatever PSK identity it deems fit.

  As an implementor and/or admin, how do I choose *pre-provisioned* PSK 
identities which won't conflict with the ones OpenSSL choose?

> The default OpenSSL NSK ticketId is 32 bytes long 
> https://github.com/openssl/openssl/blob/558ea84743918f7a93bfbfc259f86ad1fa4c8de9/include/openssl/ssl3.h#L127
>  so something has gone seriously wrong if there is a clash (poor randoms, 
> etc.). 

  i.e. "pick a long string and that should be good enough".

  If that really is the guidance, then this should also be called out in the 
draft.  PSK identities MUST be long (ideally 32 octets or more), and MUST be 
generated from a CSPRNG.

  Which then leads to the question of what will the poor user enter in a UI?  
If "end users" shouldn't be doing this, the draft also needs to call that out.

> Well, more precisely, the PSK identity is visible in the ClientHello, not the 
> actual PSK of course.

  Sure.

> And the PSK *must not* be a user-manageable string such as the
>> NAI.  On the other hand, if the PSK is sent after encryption begins, then the
>> PSK *should* be a user-manageable string such as an NAI.
> 
> https://tools.ietf.org/html/rfc8446#section-2.2 also states:
> ...
> so TLS-PSK is not suitable for a user entered low entropy password. We need a 
> PAKE for that (c.f. the ongoing CFRG PAKE assessment)

  Sure.

> There are some use cases Eliot and I are looking at related to IoT onboarding 
> where a TLS-PSK authentication has definite value, and we really don't want 
> to see this avenue closed off in EAP.

  I don't know the exact use-case, but TBH I'd suggest EAP-PWD for that.  I'm 
not sure that EAP-TLS with PSK adds any value here.

  Allowing PSK means that the draft should likely say "end users MUST NOT be 
using TLS-PSK".  Or maybe "TLS-PSK MUST be used only where systems can be 
automatically provisioned with long binary data for both PSK identity and PSK 
itself".  Or even "PSK identities and/or passwords that are composed solely of 
printable ASCII characters are likely to be humanly entered, and thus insecure".

  Which means, of course, that people will ignore that and demand simple user 
names / passwords for EAP-TLS with PSK.  Because that's ever so much easier 
than using nasty certs.

  That isn't something we should encourage.  It may be worth just forbidding it.

  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-09-18 Thread Owen Friel (ofriel)
And one other draft of interest: 
https://tools.ietf.org/html/draft-ietf-tls-external-psk-importer-00

> -Original Message-
> From: Emu  On Behalf Of Owen Friel (ofriel)
> Sent: 18 September 2019 22:42
> To: Alan DeKok ; John Mattsson
> 
> Cc: draft-ietf-emu-eap-tl...@ietf.org; EMU WG 
> Subject: Re: [Emu] POST WGLC Comments draft-ietf-emu-eap-tls13
> 
> 
> 
> > -Original Message-
> > From: Alan DeKok 
> > Sent: 18 September 2019 14:40
> > To: John Mattsson 
> > Cc: Owen Friel (ofriel) ; draft-ietf-emu-eap-
> > tl...@ietf.org; EMU WG 
> > Subject: Re: [Emu] POST WGLC Comments draft-ietf-emu-eap-tls13
> >
> >
> >
> > > On Sep 18, 2019, at 9:21 AM, John Mattsson
> >  wrote:
> > >
> > > If I understand you correctly Alan, your implementation would have
> > different databases (one resumption DB and one external PSK DB) and
> > you do not want to do two database lookups.
> >
> >   It's more about what *can* be done.  RFC 8446 Section 8.1 and 8.2
> > talk about using multiple DBs, too.
> >
> > > The format of the PSKidentities is free for the deployment to decide
> > > upon
> > and the resumption PSKs can be completely be determined by the EAP-TLS
> > implementation. Your implementation could for example put a message
> > authentication code inside the PSK identity. The MAC would be
> > calculated with a symmetric key the EAP server has randomly generated
> > by itself. I think that would solve your problem.
> >
> >   I suggest giving guidance to implementors.  Otherwise the issue is
> > open to implementation-defined behaviour, which is problematic.
> 
> Giving some implementation guidance seems appropriate here. Naively, one
> could envisage the implementation simply having a DB table for extern PSKs
> and a table that holds NewSessionTickets. An implementation could simply
> check the extern PSK table using the PskIdentity.identity, and if no match is
> found then check the NewSessionTickets table. The default OpenSSL NSK
> ticketId is 32 bytes long
> https://github.com/openssl/openssl/blob/558ea84743918f7a93bfbfc259f86a
> d1fa4c8de9/include/openssl/ssl3.h#L127 so something has gone seriously
> wrong if there is a clash (poor randoms, etc.). An additional layer of
> protection is provided by the PskBinderEntry as this is a HMAC derived using
> the PSK as one input, so the server even if there happened to be an identity
> clash, the binders will not match.
> 
> Implementations should also note
> https://tools.ietf.org/html/rfc8446#appendix-E.6.
> 
> >
> >   If PSKs are used only for resumption, the the format doesn't matter.
> > If PSKs are used for both authentication *and* resumption, then I
> > strongly recommend giving guidance.
> >
> >   For example, RFC 8446 Section 4.1.2 says:
> >
> >   struct {
> >   opaque identity<1..2^16-1>;
> >   uint32 obfuscated_ticket_age;
> >   } PskIdentity;
> >
> >   i.e. the PSK identity is an opaque binary string.  How is the user
> > supposed to enter a binary string into a "username" field in their
> > GUI?  What are the recommended formats?
> >
> >   If the ClientHello isn't encrypted, then the PSK is visible to
> > anyone (I believe).
> 
> Well, more precisely, the PSK identity is visible in the ClientHello, not the
> actual PSK of course.
> 
> And the PSK *must not* be a user-manageable string such as the
> > NAI.  On the other hand, if the PSK is sent after encryption begins,
> > then the PSK *should* be a user-manageable string such as an NAI.
> 
> https://tools.ietf.org/html/rfc8446#section-2.2 also states:
> 
> "   Note:  When using an out-of-band provisioned pre-shared secret, a
>   critical consideration is using sufficient entropy during the key
>   generation, as discussed in [RFC4086].  Deriving a shared secret
>   from a password or other low-entropy sources is not secure.  A
>   low-entropy secret, or password, is subject to dictionary attacks
>   based on the PSK binder.  The specified PSK authentication is not
>   a strong password-based authenticated key exchange even when used
>   with Diffie-Hellman key establishment.  Specifically, it does not
>   prevent an attacker that can observe the handshake from performing
>   a brute-force attack on the password/pre-shared key. "
> 
> so TLS-PSK is not suitable for a user entered low entropy password. We need
> a PAKE for that (c.f. the ongoing CFRG PAKE assessment)
> 
> 
> >
> >   I see it being useful for EAP-TLS to allow PSK authentication.  I
> > just want to be sure I know what that means, and what the impacts are.
> 
> There are some use cases Eliot and I are looking at related to IoT onboarding
> where a TLS-PSK authentication has definite value, and we really don't want
> to see this avenue closed off in EAP. Happy to provide any suggestions on
> Implementation Notes to your draft.
> 
> >
> > > I do not see how an attacker could do anything. an attacker can
> > definitely reuse any PSK identity, but would not have the
> > 

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

2019-09-18 Thread Owen Friel (ofriel)



> -Original Message-
> From: Alan DeKok 
> Sent: 18 September 2019 14:40
> To: John Mattsson 
> Cc: Owen Friel (ofriel) ; draft-ietf-emu-eap-
> tl...@ietf.org; EMU WG 
> Subject: Re: [Emu] POST WGLC Comments draft-ietf-emu-eap-tls13
> 
> 
> 
> > On Sep 18, 2019, at 9:21 AM, John Mattsson
>  wrote:
> >
> > If I understand you correctly Alan, your implementation would have
> different databases (one resumption DB and one external PSK DB) and you
> do not want to do two database lookups.
> 
>   It's more about what *can* be done.  RFC 8446 Section 8.1 and 8.2 talk
> about using multiple DBs, too.
> 
> > The format of the PSKidentities is free for the deployment to decide upon
> and the resumption PSKs can be completely be determined by the EAP-TLS
> implementation. Your implementation could for example put a message
> authentication code inside the PSK identity. The MAC would be calculated
> with a symmetric key the EAP server has randomly generated by itself. I think
> that would solve your problem.
> 
>   I suggest giving guidance to implementors.  Otherwise the issue is open to
> implementation-defined behaviour, which is problematic.

Giving some implementation guidance seems appropriate here. Naively, one could 
envisage the implementation simply having a DB table for extern PSKs and a 
table that holds NewSessionTickets. An implementation could simply check the 
extern PSK table using the PskIdentity.identity, and if no match is found then 
check the NewSessionTickets table. The default OpenSSL NSK ticketId is 32 bytes 
long 
https://github.com/openssl/openssl/blob/558ea84743918f7a93bfbfc259f86ad1fa4c8de9/include/openssl/ssl3.h#L127
 so something has gone seriously wrong if there is a clash (poor randoms, 
etc.). An additional layer of protection is provided by the PskBinderEntry as 
this is a HMAC derived using the PSK as one input, so the server even if there 
happened to be an identity clash, the binders will not match.

Implementations should also note 
https://tools.ietf.org/html/rfc8446#appendix-E.6. 

> 
>   If PSKs are used only for resumption, the the format doesn't matter.  If 
> PSKs
> are used for both authentication *and* resumption, then I strongly
> recommend giving guidance.
> 
>   For example, RFC 8446 Section 4.1.2 says:
> 
>   struct {
>   opaque identity<1..2^16-1>;
>   uint32 obfuscated_ticket_age;
>   } PskIdentity;
> 
>   i.e. the PSK identity is an opaque binary string.  How is the user supposed 
> to
> enter a binary string into a "username" field in their GUI?  What are the
> recommended formats?
> 
>   If the ClientHello isn't encrypted, then the PSK is visible to anyone (I
> believe).  

Well, more precisely, the PSK identity is visible in the ClientHello, not the 
actual PSK of course.

And the PSK *must not* be a user-manageable string such as the
> NAI.  On the other hand, if the PSK is sent after encryption begins, then the
> PSK *should* be a user-manageable string such as an NAI.

https://tools.ietf.org/html/rfc8446#section-2.2 also states:

"   Note:  When using an out-of-band provisioned pre-shared secret, a
  critical consideration is using sufficient entropy during the key
  generation, as discussed in [RFC4086].  Deriving a shared secret
  from a password or other low-entropy sources is not secure.  A
  low-entropy secret, or password, is subject to dictionary attacks
  based on the PSK binder.  The specified PSK authentication is not
  a strong password-based authenticated key exchange even when used
  with Diffie-Hellman key establishment.  Specifically, it does not
  prevent an attacker that can observe the handshake from performing
  a brute-force attack on the password/pre-shared key. "

so TLS-PSK is not suitable for a user entered low entropy password. We need a 
PAKE for that (c.f. the ongoing CFRG PAKE assessment)


> 
>   I see it being useful for EAP-TLS to allow PSK authentication.  I just want 
> to
> be sure I know what that means, and what the impacts are.

There are some use cases Eliot and I are looking at related to IoT onboarding 
where a TLS-PSK authentication has definite value, and we really don't want to 
see this avenue closed off in EAP. Happy to provide any suggestions on 
Implementation Notes to your draft.

> 
> > I do not see how an attacker could do anything. an attacker can
> definitely reuse any PSK identity, but would not have the corresponding PSK
> and the ClientHello would therefore not be accepted. The worst thing an
> attacker could do is to replay a ClientHello, then the handshake would fail
> then the EAP server verifies the Finished message.

And note https://tools.ietf.org/html/rfc8446#appendix-E.6 where there is 
guidance on how to protect from an attacker determining a valid PSK identity.
> 
>   I agree.  My larger point was that in the absence of guidance, it's 
> impossible
> to know what to do with a PSK identity.
> 
> > I don't see why this 

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

2019-09-18 Thread Alan DeKok



> On Sep 18, 2019, at 9:21 AM, John Mattsson  wrote:
> 
> If I understand you correctly Alan, your implementation would have different 
> databases (one resumption DB and one external PSK DB) and you do not want to 
> do two database lookups.

  It's more about what *can* be done.  RFC 8446 Section 8.1 and 8.2 talk about 
using multiple DBs, too.

> The format of the PSKidentities is free for the deployment to decide upon and 
> the resumption PSKs can be completely be determined by the EAP-TLS 
> implementation. Your implementation could for example put a message 
> authentication code inside the PSK identity. The MAC would be calculated with 
> a symmetric key the EAP server has randomly generated by itself. I think that 
> would solve your problem.

  I suggest giving guidance to implementors.  Otherwise the issue is open to 
implementation-defined behaviour, which is problematic.

  If PSKs are used only for resumption, the the format doesn't matter.  If PSKs 
are used for both authentication *and* resumption, then I strongly recommend 
giving guidance.

  For example, RFC 8446 Section 4.1.2 says:

  struct {
  opaque identity<1..2^16-1>;
  uint32 obfuscated_ticket_age;
  } PskIdentity;

  i.e. the PSK identity is an opaque binary string.  How is the user supposed 
to enter a binary string into a "username" field in their GUI?  What are the 
recommended formats?

  If the ClientHello isn't encrypted, then the PSK is visible to anyone (I 
believe).  And the PSK *must not* be a user-manageable string such as the NAI.  
On the other hand, if the PSK is sent after encryption begins, then the PSK 
*should* be a user-manageable string such as an NAI.

  I see it being useful for EAP-TLS to allow PSK authentication.  I just want 
to be sure I know what that means, and what the impacts are.

> I do not see how an attacker could do anything. an attacker can 
> definitely reuse any PSK identity, but would not have the corresponding PSK 
> and the ClientHello would therefore not be accepted. The worst thing an 
> attacker could do is to replay a ClientHello, then the handshake would fail 
> then the EAP server verifies the Finished message.

  I agree.  My larger point was that in the absence of guidance, it's 
impossible to know what to do with a PSK identity.

> I don't see why this would be more of a problem in EAP-TLS with TLS 1.3 that 
> in any other application of EAP-TLS.

  I agree.

  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-09-18 Thread John Mattsson
If I understand you correctly Alan, your implementation would have different 
databases (one resumption DB and one external PSK DB) and you do not want to do 
two database lookups. The format of the PSKidentities is free for the 
deployment to decide upon and the resumption PSKs can be completely be 
determined by the EAP-TLS implementation. Your implementation could for example 
put a message authentication code inside the PSK identity. The MAC would be 
calculated with a symmetric key the EAP server has randomly generated by 
itself. I think that would solve your problem.

I do not see how an attacker could do anything. an attacker can definitely 
reuse any PSK identity, but would not have the corresponding PSK and the 
ClientHello would therefore not be accepted. The worst thing an attacker could 
do is to replay a ClientHello, then the handshake would fail then the EAP 
server verifies the Finished message.

I don't see why this would be more of a problem in EAP-TLS with TLS 1.3 that in 
any other application of EAP-TLS.

/John

-Original Message-
From: Alan DeKok 
Date: Wednesday, 18 September 2019 at 15:07
To: "Owen Friel (ofriel)" 
Cc: John Mattsson , 
"draft-ietf-emu-eap-tl...@ietf.org" , EMU WG 

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

On Sep 18, 2019, at 8:45 AM, Owen Friel (ofriel)  wrote:
> 
>> 
>>  Which means that if PSK was allowed, the server can't look at the 
packets to
>> distinguish resumption from "raw" PSK.  Instead, the server has to look 
at it's
>> resumption cache which may be in a DB.
> 
> The server can use the PskIdentity in the PreSharedKeyExtension to 
differentiate between an offline PSK used for authentication vs. a PSK 
established via NewSessionTicket.

  Please define "use".  As an implementor, I can't implement "my code USES 
a field".  I need to know what the code *does* with it.

  How does the code differentiate between PSK identities?  Are the identity 
formats different?  If so, how and why?

  What prevents a malicious attacker from "using" a format which matches an 
identity coming from NewSessionTicket?

  My understanding is that the code *cannot* make any decisions simply by 
looking at the PSK identity field.  Instead, it has to look at the resumption 
cache to see if a given PSK matches a cached one.  Or maybe the code looks in a 
DB to see if the given PSK is a real "end-user" PSK in the DB.

  Simply waving your hands and saying it "uses" a field is unhelpful.  
Please give substantive feedback and/or advice about what the code *does*.

  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-09-18 Thread Alan DeKok
  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


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

2019-09-18 Thread Alan DeKok
On Sep 18, 2019, at 8:45 AM, Owen Friel (ofriel)  wrote:
> 
>> 
>>  Which means that if PSK was allowed, the server can't look at the packets to
>> distinguish resumption from "raw" PSK.  Instead, the server has to look at 
>> it's
>> resumption cache which may be in a DB.
> 
> The server can use the PskIdentity in the PreSharedKeyExtension to 
> differentiate between an offline PSK used for authentication vs. a PSK 
> established via NewSessionTicket.

  Please define "use".  As an implementor, I can't implement "my code USES a 
field".  I need to know what the code *does* with it.

  How does the code differentiate between PSK identities?  Are the identity 
formats different?  If so, how and why?

  What prevents a malicious attacker from "using" a format which matches an 
identity coming from NewSessionTicket?

  My understanding is that the code *cannot* make any decisions simply by 
looking at the PSK identity field.  Instead, it has to look at the resumption 
cache to see if a given PSK matches a cached one.  Or maybe the code looks in a 
DB to see if the given PSK is a real "end-user" PSK in the DB.

  Simply waving your hands and saying it "uses" a field is unhelpful.  Please 
give substantive feedback and/or advice about what the code *does*.

  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-09-18 Thread Owen Friel (ofriel)



> -Original Message-
> From: Emu  On Behalf Of Alan DeKok
> Sent: 12 September 2019 16:28
> To: John Mattsson 
> Cc: draft-ietf-emu-eap-tl...@ietf.org; EMU WG 
> Subject: Re: [Emu] POST WGLC Comments draft-ietf-emu-eap-tls13
> 
> On Sep 12, 2019, at 10:55 AM, John Mattsson
>  wrote:
> >
> >> See Section 2.1.2.  TLS 1.3 uses PSK for resumption.  As a result, we
> *cannot* use PSK for >authentication in EAP-TLS.
> >
> > I don't understand why this could not be done. My view is that allowing PSK
> authentication would be quite easy.
> 
>   How would systems tell the difference between "raw" PSK and
> "resumption" PSK?
> 
>   When allowing resumption, the server has sent a PSK identity in a
> NewSessionTicket message.  The client caches this and re-uses this.  But the
> client signals that it is performing resumption via the act of using PSK.  
> There's
> nothing else.
> 
>   Which means that if PSK was allowed, the server can't look at the packets to
> distinguish resumption from "raw" PSK.  Instead, the server has to look at 
> it's
> resumption cache which may be in a DB.

The server can use the PskIdentity in the PreSharedKeyExtension to 
differentiate between an offline PSK used for authentication vs. a PSK 
established via NewSessionTicket.

There should be no problem here, and the statement

" Pre-Shared Key (PSK) authentication SHALL NOT be used except
   for resumption. "

should be updated to clarify.

> 
> >>> While there is the EAP-PSK method, I would much rather use EAP-TLS
> with PSK because it >provides identity protection and perfect forward
> secrecy, unlike EAP-PSK.
> >>
> >> Use EAP-PWD for that.
> >
> > Standardizing EAP-TLS should only be done if it has some significant
> advantages over EAP-PWD, and there are people wanting to implement and
> use it. 3GPP is e.g. adding  identity protection and perfect forward secrecy 
> to
> EAP-AKA instead.
> 
>   I would prefer to forbid PSK in EAP-TLS.
> 
>   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] Re-charter text

2019-09-18 Thread Georgios Z. Papadopoulos
Dear Joe, Mohit and all,

In overall I find the text well written, while the objectives well defined.
Below I have very few comments :

* TLS is not defined. 
* Perfect Forward Secrecy (PFS) is defined twice.
* - An update to enable the use of TLS 1.3 in the context of EAP-TLS (RFC 
5216). This document will pdate the security considerations relating to 
EAP-TLS, document the implications of using new vs. old TLS versions, add any 
recently gained new knowledge on vulnerabilities, and discuss the possible 
implications of pervasive surveillance.

This last point, maybe could be divided in several sentences, since I find it 
too long and, thus, hard to follow.

Many thanks for your efforts.

Best regards,
Georgios


> On Sep 11, 2019, at 20:50, Mohit Sethi M  wrote:
> 
> Dear all,
> 
> Please send in your comments on the charter text by Wednesday, September 18, 
> 2019. 
> Joe and Mohit
> On 8/21/19 11:13 AM, Mohit Sethi M wrote:
>> Dear all,
>> 
>> Thank you for a productive meeting @ IETF 105. We had discussed the new 
>> charter text during the working group session in Montreal. Please find the 
>> same text below. This text builds upon our current charter. Feel free to 
>> suggest changes. RFC 2418 section 2.2 
>> https://tools.ietf.org/html/rfc2418#section-2.2 
>>  says the following about a 
>> working group charter:
>> 
>>>2. Specifies the direction or objectives of the working group and
>>>   describes the approach that will be taken to achieve the goals;
>> 
>> Please keep this in mind when suggesting changes. Once the text is ready, we 
>> will send it to the IESG for review.
>> Joe and Mohit
>> 
>> 
>> 
>> The Extensible Authentication Protocol (EAP) [RFC 3748] is a network access 
>> authentication framework used, for instance, in VPN and mobile networks. EAP 
>> itself is a simple protocol and actual authentication happens in EAP 
>> methods. Several EAP methods have been developed at the IETF and support for 
>> EAP exists in a broad set of devices. Previous larger EAP-related efforts at 
>> the IETF included rewriting the base EAP protocol specification and the 
>> development of several standards track EAP methods.
>> 
>> EAP methods are generally based on existing security technologies such as 
>> TLS and SIM cards. Our understanding of security threats is continuously 
>> evolving. This has driven the evolution of several of these underlying 
>> technologies. As an example, IETF has standardized a new and improved 
>> version of TLS in RFC 8446. The group will therefore provide guidance and 
>> update EAP method specifications where necessary to enable the use of new 
>> versions of these underlying technologies. 
>> 
>> At the same time, some new use cases for EAP have been identified. EAP is 
>> now more broadly in mobile network authentication. The group will update 
>> existing EAP methods such as EAP-AKA' to stay in sync with updates to the 
>> referenced 3GPP specifications. RFC 7258 notes that pervasive monitoring is 
>> an attack. Perfect Forward Secrecy (PFS) is an important security property 
>> for modern protocols to thwart pervasive monitoring. The group will 
>> therefore work on an extension to EAP-AKA' for providing Perfect Forward 
>> Secrecy (PFS).
>> 
>> Out-of-band (OOB) refers to a separate communication channel independent of 
>> the primary in-band channel over which the actual network communication 
>> takes place. OOB channels are now used for authentication in a variety of 
>> protocols and devices (draft-ietf-oauth-device-flow-13, WhatsApp Web, etc.). 
>> Many users are accustomed to tapping NFC or scanning QR codes. However, EAP 
>> currently does not have any standard methods that support authentication 
>> based on OOB channels. The group will therefore work on an EAP method where 
>> authentication is based on an out-of-band channel between the peer and the 
>> server.
>> 
>> EAP authentication is based on credentials available on the peer and the 
>> server. However, some EAP methods use credentials that are time or domain 
>> limited (such as EAP-POTP), and there may be a need for creating long term 
>> credentials for re-authenticating the peer in a more general context. The 
>> group will investigate minimal mechanisms with which limited-use EAP 
>> authentication credentials can be used for creating general-use long-term 
>> credentials.
>> 
>> In summary, the working group shall produce the following documents:
>> 
>>  - An update to enable the use of TLS 1.3 in the context of EAP-TLS (RFC 
>> 5216). This document will pdate the security considerations relating to 
>> EAP-TLS, document the implications of using new vs. old TLS versions, add 
>> any recently gained new knowledge on vulnerabilities, and discuss the 
>> possible implications of pervasive surveillance.
>> 
>>  - Several EAP methods such EAP-TTLS and EAP-FAST use an outer TLS tunnel. 
>> Provide guidance or