Subject: Re: [Emu] Re-charter text

From: "Dr. Pala" <[email-masked]>
Date: Mon, 14 Oct 2019 18:11:24 -0600

Hi Mohit, all,

sorry for the long delay in replying (probably mute at this point), 
however I think the new text looks great. The only possible change I 
would provide is the possibility to restrict the scope for the 
credentials management part. In particular, I would change the following:

    The group will investigate minimal mechanisms with which limited-use
    EAP authentication credentials can be used for creating general-use
    long-term credentials.

With something scoped to the credentials for accessing the network 
itself (instead of a generic credentials provisioning mechanism):

    The group will investigate minimal mechanisms to manage long-term
    credentials that are use to access the network.

This would probably make the management of credentials scoped to 
providing and managing the access credentials that the network is 
authoritative for - I would feel a bit "un-ease" to provide mechanisms 
to provision credentials to be used outside the access network context 
(just because it might not be the best enforcement point).

Given that I would be happier with a reduced scope (unless there are 
good reasons not to limit the scope), I am also happy with the current 
text (since allows EAP-CREDS to be discussed).

Thanks,
Max

On 9/21/19 6:16 AM, Mohit Sethi M wrote:
>
> Hi Georgios,
>
> Thanks for reading the charter. I have addressed your comments on 
> github. Here is the updated text:
> https://github.com/emu-wg/charter/blob/master/emu-charter.md
>
> and here is the diff from the previous version:
> https://github.com/emu-wg/charter/commit/be1bf557355ecba5d5ee35ab27f3e8fae8c06eef
>
> --Mohit
>
> On 9/18/19 11:37 AM, Georgios Z. Papadopoulos wrote:
>> 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 <[email-masked] 
>>> <mailto:[email-masked]>> 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 
>>>> <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 update the relevant specifications 
>>>> explaining how those EAP methods (PEAP/TTLS/TEAP) will work with 
>>>> TLS 1.3. This will also involve maintenance work based on erratas 
>>>> found in published specifications (such as EAP-TEAP).
>>>>
>>>> - Define session identifiers for fast re-authentication for 
>>>> EAP-SIM, EAP-AKA, and EAP-AKA’. The lack of this definition is a 
>>>> recently discovered bug in the original RFCs.
>>>>
>>>> - Update the EAP-AKA' specification (RFC 5448) to ensure that its 
>>>> capability to provide a cryptographic binding to network context 
>>>> stays in sync with updates to the referenced 3GPP specifications. 
>>>> The document will also contain any recently gained new knowledge on 
>>>> vulnerabilities or the possible implications of pervasive surveillance.
>>>>
>>>> - Develop an extension to EAP-AKA' such that Perfect Forward 
>>>> Secrecy can be provided. There may also be privacy improvements 
>>>> that have become feasible with the  introduction of recent identity 
>>>> privacy improvements in 3GPP networks.
>>>>
>>>> - Gather experience regarding the use of large certificates and 
>>>> long certificate chains in the context of EAP-TLS (all versions), 
>>>> as some implementations and access networks may limit the number of 
>>>> EAP packet exchanges that can be handled. Document operational 
>>>> recommendations or other mitigation strategies to avoid issues.
>>>>
>>>> - Define a standard EAP method for mutual authentication between a 
>>>> peer and a server that is based on an out-of-band channel. The 
>>>> method itself shall be independent of the underlying OOB channel 
>>>> and shall support a variety of OOB channels such as NFC, 
>>>> dynamically generated QR codes, audio, and visible light.
>>>>
>>>> - Define mechanisms by which EAP methods can support creation of 
>>>> long-term credentials for the peer based on initial limited-use 
>>>> credentials.
>>>>
>>>> The working group is expected to stay in close collaboration with 
>>>> the EAP deployment community, the TLS working group (for EAP-TLS 
>>>> work), and the 3GPP security architecture group (for EAP-AKA' work)
>>>>
>>>> ------------------------
>>>>
>>>>
>>>> _______________________________________________
>>>> Emu mailing list
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/listinfo/emu
>>> _______________________________________________
>>> Emu mailing list
>>> [email-masked] <mailto:[email-masked]>
>>> https://www.ietf.org/mailman/listinfo/emu
>>
>>
>> _______________________________________________
>> Emu mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/emu
>
> _______________________________________________
> Emu mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/emu
-- 
Best Regards,
Massimiliano Pala, Ph.D.
OpenCA Labs Director
OpenCA Logo

---

From: Mohit Sethi M <[email-masked]>
Date: Tue, 15 Oct 2019 08:07:26 +0000

Dear Dr. Pala,

I think we need to be more prudent when using terms such as "credential provisioning" and "credential management". The bullet later on in the current charter text specifically says that the credentials are for the EAP peer:

Define mechanisms by which EAP methods can support creation of long-term credentials for the peer based on initial limited-use credentials.

Given that you are happy with the current text, I have a preference to leave it in its current form. We are hoping that the IESG will discuss this in their telechat on 31 October (which is also the last chance before Singapore).

--Mohit

On 10/15/19 3:11 AM, Dr. Pala wrote:

Hi Mohit, all,

sorry for the long delay in replying (probably mute at this point), however I think the new text looks great. The only possible change I would provide is the possibility to restrict the scope for the credentials management part. In particular, I would change the following:

The group will investigate minimal mechanisms with which limited-use EAP authentication credentials can be used for creating general-use long-term credentials.

With something scoped to the credentials for accessing the network itself (instead of a generic credentials provisioning mechanism):

The group will investigate minimal mechanisms to manage long-term credentials that are use to access the network.

This would probably make the management of credentials scoped to providing and managing the access credentials that the network is authoritative for - I would feel a bit "un-ease" to provide mechanisms to provision credentials to be used outside the access network context (just because it might not be the best enforcement point).

Given that I would be happier with a reduced scope (unless there are good reasons not to limit the scope), I am also happy with the current text (since allows EAP-CREDS to be discussed).

Thanks,
Max

Hi Georgios,

Thanks for reading the charter. I have addressed your comments on github. Here is the updated text:
https://github.com/emu-wg/charter/blob/master/emu-charter.md

--Mohit

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.

Best regards,
Georgios

On Sep 11, 2019, at 20:50, Mohit Sethi M <[email-masked]<mailto:[email-masked]>> wrote:

Dear all,

Please send in your comments on the charter text by Wednesday, September 18, 2019.

Joe and Mohit

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:

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.

 - 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 update the relevant specifications explaining how those EAP methods (PEAP/TTLS/TEAP) will work with TLS 1.3. This will also involve maintenance work based on erratas found in published specifications (such as EAP-TEAP).

- Define session identifiers for fast re-authentication for EAP-SIM, EAP-AKA, and EAP-AKA’. The lack of this definition is a recently discovered bug in the original RFCs.

- Update the EAP-AKA' specification (RFC 5448) to ensure that its capability to provide a cryptographic binding to network context stays in sync with updates to the referenced 3GPP specifications. The document will also contain any recently gained new knowledge on vulnerabilities or the possible implications of pervasive surveillance.

- Develop an extension to EAP-AKA' such that Perfect Forward Secrecy can be provided. There may also be privacy improvements that have become feasible with the  introduction of recent identity privacy improvements in 3GPP networks.

- Gather experience regarding the use of large certificates and long certificate chains in the context of EAP-TLS (all versions), as some implementations and access networks may limit the number of EAP packet exchanges that can be handled. Document operational recommendations or other mitigation strategies to avoid issues.

- Define a standard EAP method for mutual authentication between a peer and a server that is based on an out-of-band channel. The method itself shall be independent of the underlying OOB channel and shall support a variety of OOB channels such as NFC, dynamically generated QR codes, audio, and visible light.

- Define mechanisms by which EAP methods can support creation of long-term credentials for the peer based on initial limited-use credentials.

The working group is expected to stay in close collaboration with the EAP deployment community, the TLS working group (for EAP-TLS work), and the 3GPP security architecture group (for EAP-AKA' work)

------------------------

_______________________________________________
Emu mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/emu

_______________________________________________
Emu mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/emu

_______________________________________________
Emu mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/emu

_______________________________________________
Emu mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/emu

--
Best Regards,
Massimiliano Pala, Ph.D.
OpenCA Labs Director
[OpenCA Logo]

_______________________________________________
Emu mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/emu

---

From: "Dr. Pala" <[email-masked]>
Date: Wed, 23 Oct 2019 18:11:46 -0600

Hi Mohit, all,

I have a question for you - in which sense you mean "prudent" ?

Are you saying that creating "general-use" credentials or provisioning 
credentials is different ? Creating "general-use" credentials instead of 
provisioning/managing the Access Network credentials seems way more 
scary and generic than the text I proposed (which limits the scope of 
the credentials you should manage with EAP to the credentials that are 
used to access the network), therefore, because of your comment, I would 
like to have some clarifications here because my interpretation could be 
different than yours... and, based on that, my "happiness" level can be 
different than initially reported :D

In particular, I would like to understand if the following operations 
can be supported by an EAP method:

  * Renewing Existing credentials (i.e., maybe credentials that were
    generated via the EAP method in the first place)
  * Removing Existing credentials (i.e., the network will not use that
    credential anymore, therefore it tasks the device to remove them)

Personally, for the work we are doing in different types of Access 
Networks (3gpp, CBRS-A, WiFi / WFA, and DOCSIS(r)), I think that the 
advantage of the EAP method is about managing the credentials that are 
also consumed by the EAP framework - I would not let my 
application-layer credentials be managed by the Access Network... and 
the opposite should apply as well, IMHO.

/*As long as both views are supported, I am ok with the text. */

However, if your interpretation of the charter would not allow 
operations like registering an existing long-term credential to access 
the network (e.g., the device cannot generate/use a different one), 
renewing the credentials used to access the network, or 
deleting/removing/revoking existing credentials (i.e., no need to keep a 
private key or secrets around if it is not useful), then I would not be 
happy with the text.

Can you please provide clarifications on the above points ?

Also, you mention that there is an IESG meeting on October 31st - is it 
possible to participate to that meeting ? If so, can you please let us 
know the meetings' details... ?

Last but not least - I sent you the request earlier for a slot at IETF 
106 for EAP-CREDS and I would like to confirm again with you we have the 
slot (I do not recall seeing your reply to that message).

Cheers,
Max

On 10/15/19 2:07 AM, Mohit Sethi M wrote:
>
> Dear Dr. Pala,
>
> I think we need to be more prudent when using terms such as 
> "credential provisioning" and "credential management". The bullet 
> later on in the current charter text specifically says that the 
> credentials are for the EAP peer:
>
>> |Define mechanisms by which EAP methods can support creation of 
>> credentials.|
> Given that you are happy with the current text, I have a preference to 
> leave it in its current form. We are hoping that the IESG will discuss 
> this in their telechat on 31 October (which is also the last chance 
> before Singapore).
>
> --Mohit
>
>>     The group will investigate minimal mechanisms with which
>>     limited-use EAP authentication credentials can be used for
>>     creating general-use long-term credentials.
>>
>> authoritative for - I would feel a bit "un-ease" to provide 
>> mechanisms to provision credentials to be used outside the access 
>> network context (just because it might not be the best enforcement 
>> point).
>>
>> good reasons not to limit the scope), I am also happy with the 
>> current text (since allows EAP-CREDS to be discussed).
>>
>> Thanks,
>> Max
>>
>>
>>>> * - 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.
>>>>
>>>>> On Sep 11, 2019, at 20:50, Mohit Sethi M 
>>>>> <[email-masked] <mailto:[email-masked]>> 
>>>>> 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:
>>>>>>
>>>>>> 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
>>>>>>
>>>>>> ------------------------
>>>>>>
>>>>>> 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.
>>>>>>
>>>>>> 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).
>>>>>>
>>>>>> 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.
>>>>>>
>>>>>> 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.
>>>>>>
>>>>>>  - 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 update the relevant 
>>>>>> specifications explaining how those EAP methods (PEAP/TTLS/TEAP) 
>>>>>> will work with TLS 1.3. This will also involve maintenance work 
>>>>>> based on erratas found in published specifications (such as 
>>>>>> EAP-TEAP).
>>>>>>
>>>>>> The document will also contain any recently gained new knowledge 
>>>>>> on vulnerabilities or the possible implications of pervasive 
>>>>>> surveillance.
>>>>>>
>>>>>> that have become feasible with the  introduction of recent 
>>>>>> identity privacy improvements in 3GPP networks.
>>>>>>
>>>>>> as some implementations and access networks may limit the number 
>>>>>> of EAP packet exchanges that can be handled. Document operational 
>>>>>> - Define a standard EAP method for mutual authentication between 
>>>>>> a peer and a server that is based on an out-of-band channel. The 
-- 
Best Regards,
Massimiliano Pala, Ph.D.
OpenCA Labs Director
OpenCA Logo

---

From: Mohit Sethi M <[email-masked]>
Date: Thu, 24 Oct 2019 09:30:16 +0000

Dear Dr. Pala,

I find your behavior highly unprofessional and erratic. The charter text was sent to you and other authors in a private email on the 18th of July, 2019. The purpose of sending this privately was to allow the authors of various proposals to have a look before we spend valuable meeting time discussing the text at the IETF 105 meeting in Montreal. We never received a response from you.

The charter text was then discussed during the EMU session in Montreal on 24th of July. Based on our discussions at the meeting in Montreal, we posted a new version to the list on 21st of August (https://mailarchive.ietf.org/arch/msg/emu/MhvrlqseZN5ODvyXqsMaK4W67_I). We then posted our charter to our github page and asked for feedback with a deadline of 18th of September (https://mailarchive.ietf.org/arch/msg/emu/sIRUpcQS8dloK7JhWEOSamr8KHo). We never received any comments from you. I understand that you are a busy man, but so are we all. I hope you can have some respect for other people's time as well.

I am not a member of the IESG and don't join any of their meetings. The IESG meets biweekly on every Thursday to discuss various documents, charter text, and other administrative matter. For more information on who are members of the IESG, please see: https://www.ietf.org/about/groups/iesg/. On the same page you can find the webex link to their meetings and you are always welcome to join as an observer. Please be assured that the IETF is a very open organization and doesn't take secret decisions behind closed doors. I will not be involved with the IESG decision on whether they approve the charter or not.

Then you accuse me of not replying to your private request for presenting during the EMU session at IETF 106. Please know that EMU is not run like a private club with me as its boss. I am only one of the 2 co-chairs and I strive to be as neutral as possible to all drafts, presentation requests, etc.. You should send your request through the usual channel of [email-masked] so that the chairs can take a decision together. I don't want to handle matters without involving my co-chair (and our AD if needed). Also, asking for time does not mean that we can guarantee it immediately. We have to wait for all the presentation requests to come in and then prioritize working group documents. If there is agenda time remaining, we have always allowed and encouraged presentation of new work. We cannot provide any guarantees if there will presentation time for EAP-Creds at this stage. However, we can provide a guarantee that we will try our best to accommodate it.

Then you write "As long as both views are supported, I am ok with the text". This is almost holding the working group as hostage unless they agree with your understanding. Some technical comments:

- I think the current text is broad enough to support renewing of credentials. Revoking of credentials has always existed in EAP/AAA architecture. But please note that this does not imply a working group consensus on what you are suggesting. Credential management can involve many more things and not just renewing/revocation. Therefore, I had suggested that we are more "prudent", i.e. "careful", in our choice of words.

- EAP is not run in isolation and often may take into account information from various layers above or below. For example, EAP implementations can check whether the SSID/BSSID that the peer is connecting through is correct. While some may call this stack violation, other security folks call this channel binding. I can certainly see that some applications may want to bind the application authentication with the underlying EAP authentication. In fact, in 5G, MSK and EMSK exported from EAP-AKA` is used for a variety of other purposes (such as AKMA and GBA).

As a final remark, it is easy to complain about others. I strongly encourage you to take a pause and self-introspect before accusing other people of not replying to emails or not writing the text exactly as you want or not doing things that make you happy.

--Mohit

On 10/24/19 3:11 AM, Dr. Pala wrote:

Hi Mohit, all,

Are you saying that creating "general-use" credentials or provisioning credentials is different ? Creating "general-use" credentials instead of provisioning/managing the Access Network credentials seems way more scary and generic than the text I proposed (which limits the scope of the credentials you should manage with EAP to the credentials that are used to access the network), therefore, because of your comment, I would like to have some clarifications here because my interpretation could be different than yours... and, based on that, my "happiness" level can be different than initially reported :D

In particular, I would like to understand if the following operations can be supported by an EAP method:

  *   Renewing Existing credentials (i.e., maybe credentials that were generated via the EAP method in the first place)
  *   Removing Existing credentials (i.e., the network will not use that credential anymore, therefore it tasks the device to remove them)

Personally, for the work we are doing in different types of Access Networks (3gpp, CBRS-A, WiFi / WFA, and DOCSIS(r)), I think that the advantage of the EAP method is about managing the credentials that are also consumed by the EAP framework - I would not let my application-layer credentials be managed by the Access Network... and the opposite should apply as well, IMHO.

As long as both views are supported, I am ok with the text.

However, if your interpretation of the charter would not allow operations like registering an existing long-term credential to access the network (e.g., the device cannot generate/use a different one), renewing the credentials used to access the network, or deleting/removing/revoking existing credentials (i.e., no need to keep a private key or secrets around if it is not useful), then I would not be happy with the text.

Also, you mention that there is an IESG meeting on October 31st - is it possible to participate to that meeting ? If so, can you please let us know the meetings' details... ?

Last but not least - I sent you the request earlier for a slot at IETF 106 for EAP-CREDS and I would like to confirm again with you we have the slot (I do not recall seeing your reply to that message).

Cheers,
Max

Dear Dr. Pala,

--Mohit

Hi Mohit, all,

Thanks,
Max

Hi Georgios,

--Mohit

* TLS is not defined.

Best regards,
Georgios

Dear all,

Joe and Mohit

Dear all,

Joe and Mohit

------------------------

------------------------

--
Best Regards,
Massimiliano Pala, Ph.D.
OpenCA Labs Director
[OpenCA Logo]

--
Best Regards,
Massimiliano Pala, Ph.D.
OpenCA Labs Director
[OpenCA Logo]

---

From: "Dr. Pala" <[email-masked]>
Date: Thu, 24 Oct 2019 08:12:40 -0600

Hi Mohit,

On 10/24/19 3:30 AM, Mohit Sethi M wrote:
> [ ... ]

I replied privately to the first part of this e-mail - I apologize if my 
e-mail did offend you or was in any way inappropriate. To clarify, my 
questions were in reply to Mohit's comments to my previous e-mail on the 
topic [*]. This said, I would like to stay on topic and focus on the 
technical contents. In particular:

> - I think the current text is broad enough to support renewing of 
> credentials. Revoking of credentials has always existed in EAP/AAA 
> architecture. But please note that this does not imply a working group 
> consensus on what you are suggesting. Credential management can 
> involve many more things and not just renewing/revocation. Therefore, 
> I had suggested that we are more "prudent", i.e. "careful", in our 
> choice of words.
>
I understand - thanks for clarifying the point. My question was about 
understanding if the renewal operation was something supported by the 
charter. This was my initial interpretation too, but I just asked in 
response of your comment about being "prudent".

> - EAP is not run in isolation and often may take into account 
> information from various layers above or below. For example, EAP 
> implementations can check whether the SSID/BSSID that the peer is 
> connecting through is correct. While some may call this stack 
> violation, other security folks call this channel binding. I can 
> certainly see that some applications may want to bind the application 
> authentication with the underlying EAP authentication. In fact, in 5G, 
> MSK and EMSK exported from EAP-AKA` is used for a variety of other 
> purposes (such as AKMA and GBA).
>
> [ ... ]
>
That is true - I did not think about these use cases. Indeed, EAP can be 
used (especially in 3gpp/mobile networks) to leverage the USIM 
credentials for, for example, N3IWF/W-AGF for non-3GPP access. However, 
usually, also in that model is still the Core (i.e., your "home" 
network) that handles the credentials, which might not be the same as 
the access network (i.e., roaming) - which is more similar to my 
use-case. The one I was referring to is the situation where the Access 
Network validates your credentials that were issued somewhere else and 
now it wants to renew your credentials with something else: this is 
where it gets tricky about deciding who is the authoritative source of 
the credentials.

Anyhow, thanks for clarifying the interpretation of the charter.

Cheers,
Max

[*] = I think it is unfair to call me "unprofessional" and "erratic" in 
a public forum - I contacted the chair(s) separately to clarify the 
situation.

>> Are you saying that creating "general-use" credentials or 
>> provisioning credentials is different ? Creating "general-use" 
>> credentials instead of provisioning/managing the Access Network 
>> credentials seems way more scary and generic than the text I proposed 
>> (which limits the scope of the credentials you should manage with EAP 
>> to the credentials that are used to access the network), therefore, 
>> because of your comment, I would like to have some clarifications 
>> here because my interpretation could be different than yours... and, 
>> based on that, my "happiness" level can be different than initially 
>> reported :D
>>
>>   * Removing Existing credentials (i.e., the network will not use
>>     that credential anymore, therefore it tasks the device to remove
>>     them)
>>
>> advantage of the EAP method is about managing the credentials that 
>> are also consumed by the EAP framework - I would not let my 
>> operations like registering an existing long-term credential to 
>> access the network (e.g., the device cannot generate/use a different 
>> one), renewing the credentials used to access the network, or 
>> deleting/removing/revoking existing credentials (i.e., no need to 
>> keep a private key or secrets around if it is not useful), then I 
>> would not be happy with the text.
>>
>> Also, you mention that there is an IESG meeting on October 31st - is 
>> it possible to participate to that meeting ? If so, can you please 
>> let us know the meetings' details... ?
>>
>> Last but not least - I sent you the request earlier for a slot at 
>> IETF 106 for EAP-CREDS and I would like to confirm again with you we 
>> have the slot (I do not recall seeing your reply to that message).
>>
>> Cheers,
>> Max
>>
>>
>>> Given that you are happy with the current text, I have a preference 
>>> to leave it in its current form. We are hoping that the IESG will 
>>> discuss this in their telechat on 31 October (which is also the last 
>>> chance before Singapore).
>>>
>>> --Mohit
>>>
>>>> however I think the new text looks great. The only possible change 
>>>> I would provide is the possibility to restrict the scope for the 
>>>>     The group will investigate minimal mechanisms to manage
>>>>     long-term credentials that are use to access the network.
>>>>
>>>> Given that I would be happier with a reduced scope (unless there 
>>>> are good reasons not to limit the scope), I am also happy with the 
>>>>>> 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.
>>>>>>
>>>>>>>> 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 
>>>>>>>> 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.
>>>>>>>>
>>>>>>>> property for modern protocols to thwart pervasive monitoring. 
>>>>>>>> The group will therefore work on an extension to EAP-AKA' for 
>>>>>>>> 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.
>>>>>>>>
>>>>>>>> considerations relating to EAP-TLS, document the implications 
>>>>>>>> of using new vs. old TLS versions, add any recently gained new 
>>>>>>>> specifications explaining how those EAP methods 
>>>>>>>> (PEAP/TTLS/TEAP) will work with TLS 1.3. This will also involve 
>>>>>>>> maintenance work based on erratas found in published 
>>>>>>>> specifications (such as EAP-TEAP).
>>>>>>>>
>>>>>>>> EAP-SIM, EAP-AKA, and EAP-AKA’. The lack of this definition is 
>>>>>>>> a recently discovered bug in the original RFCs.
>>>>>>>>
>>>>>>>> - Update the EAP-AKA' specification (RFC 5448) to ensure that 
>>>>>>>> its capability to provide a cryptographic binding to network 
>>>>>>>> context stays in sync with updates to the referenced 3GPP 
>>>>>>>> specifications. The document will also contain any recently 
>>>>>>>> gained new knowledge on vulnerabilities or the possible 
>>>>>>>> long certificate chains in the context of EAP-TLS (all 
>>>>>>>> versions), as some implementations and access networks may 
>>>>>>>> limit the number of EAP packet exchanges that can be handled. 
>>>>>>>> Document operational recommendations or other mitigation 
>>>>>>>> strategies to avoid issues.
>>>>>>>>
>>>>>>>> - Define a standard EAP method for mutual authentication 
>>>>>>>> between a peer and a server that is based on an out-of-band 
>>>>>>>> channel. The method itself shall be independent of the 
>>>>>>>> underlying OOB channel and shall support a variety of OOB 
>>>>>>>> channels such as NFC, dynamically generated QR codes, audio, 
>>>>>>>> and visible light.
>>>>>>>>
>>>>>>>> - Define mechanisms by which EAP methods can support creation 
>>>>>>>> of long-term credentials for the peer based on initial 
>>>>>>>> limited-use credentials.
>>>>>>>>
>>>>>>>> The working group is expected to stay in close collaboration 
>>>>>>>> with the EAP deployment community, the TLS working group (for 
>>>>>>>> EAP-TLS work), and the 3GPP security architecture group (for 
>>>>>>>> EAP-AKA' work)
>>>>>>>>
>>>>>>>> ------------------------
>>>>>>>>
>>>>>>>>
-- 
Best Regards,
Massimiliano Pala, Ph.D.
OpenCA Labs Director
OpenCA Logo