Hi Mohit, all, So, if I may summarize the mail exchange, we agree that:
* We can continue to discuss the issue within the EMU umbrella as long
as it will not be overwhelming (it seems there is not much
discussion within the ML now, so it might be a good time to work on
these items)
* It would be useful to have a conversation with IEEE around the idea
of using EAP as a provisioning channel. My question here is - does
anybody have plans to attend the IEEE meeting and/or report on
what's the sentiment there around this idea?
Given the above, I would like to understand what would be the possible
options for provisioning protocols. In particular, I would like to have
the input from the WG about EAP-TEAP extension vs. new EAP mechanisms.
The use of EAP-TEAP extension seems to be a good approach - it already
supports EST and can be extended to support other provisioning
protocols. However, for protocols that might not require the use of a
protected channel (e.g., because messages are signed and no secrets are
exposed), it might be useful to have the option of not requiring
EAP-TEAM as the "outer shell".
On the other hand, the definition of extensions for EAP-TEAP might
provide the needed push for seeing the deployment of the mechanisms
(which today is still, as far as I know, very limited).
What do you think?
Cheers,
Max
On 8/7/18 1:57 PM, Mohit Sethi wrote:
> Hi all,
>
> Please see our responses inline.
>
> Joe and Mohit
>
> On 08/03/2018 06:02 PM, Eliot Lear wrote:
>>
>> Hi Max and group,
>>
>> I want to direct my response to you in the context of
>> draft-lear-eap-teap-brski. While I wasn't in Montreal, I was in
>> London, and it seems like there is a generally favorable view of the
>> draft with two caveats:
>>
>> 1. The charter issue that you discuss below; and
>> 2. a concern that perhaps extensions to TEAP won't get deployed
>> because TEAP isn't well deployed.
>>
> There were also some other comments during the meeting. Please have a
> look at the detailed minutes:
> https://datatracker.ietf.org/meeting/102/materials/minutes-102-emu-00
>>
>> I want to address the 2nd point first. My view is that TEAP hasn't
>> seen wide deployment because the use case it thus far addresses is
>> primarily focused on is well handled by EAP-FAST, and that is quite
>> heavily deployed. What we are talking about is an expanded use case
>> that would provide some additional reason to deploy TEAP. I think
>> everyone understands the wireless chicken-and-egg problem, tho some
>> see different ways of solving it.
>>
>> Michael has pointed out that the IEEE is having a meeting opposite
>> the IETF in Bangkok. As this directly relates to them, it might make
>> sense for some of us to gather together, either formally or
>> informally or however between the two meetings and talk through what
>> we think "Good" looks like. As to how to progress discussion, we'd
>> like to keep things open. We know we have a problem. In the
>> enterprise space it's particularly interesting interesting. When in
>> noisy environments like cities, the problem is even more interesting.
>>
> An informal discussion with the folks at IEEE to understand the
> problems, requirements and various proposals would be a good approach.
>>
>> In the interim, should we continue to discuss this on EMU? If not,
>> can we get a non-wg mailing list for this purpose, and maybe even
>> advertise it over to the IEEE 802.11 folk so that we could have good
>> industry input? I could see such a list covering eap-provisioning
>> which seems to handle a much of what you mention below (sorry for
>> taking so long to get back to your message). Does that sound like a
>> reasonable approach? That way the ADs can occasionally see how the
>> work is progressing and then make decisions.
>>
> The discussion can continue on the EMU list as long as it doesn't
> become a significant distraction.
>>
>> Thanks,
>>
>> Eliot
>>
>>
>> On 21.07.18 00:20, Dr. Pala wrote:
>>>
>>> Hi Emu-ers,
>>>
>>> I wanted to follow up the discussion from today's meeting. In
>>> particular, there is some work that has been proposed that might
>>> require re-chartering as indicated by Ekr and supported by the Chair(s).
>>>
>>> I would like to push forward the request for re-chartering, in
>>> particular, I would like to add the definition of one (or more)
>>> EAP-based credentials provisioning mechanisms that would fit many
>>> use cases that we are currently working on in different organizations.
>>>
>>> In particular, the use cases that I am referring to are the following:
>>>
>>> * *Cellular Networks.* The provisioning of Certificates (or other
>>> credentials) to enable the use of EAP methods in different
>>> environments (e.g., CBRS Alliance, MutleFire, etc.) has been a
>>> problem that the current ecosystem have not addressed
>>> efficiently. The use of OSU servers and the complexity (and
>>> associated risks) of allowing (partial) IP access to
>>> non-authenticated devices has limited the possibility for
>>> in-line provisioning of devices. The use of an EAP-based
>>> mechanism that can be used for credentials provisioning (and
>>> renewal) would greatly improve the feasibility of in-band
>>> credentials deployment. This authentication mechanism would
>>> improve the possibility to use 4G\LTE (and future 5G) networks
>>> for IoT credentials management which, today, seems to be ignored
>>> because of the complexity required on the device.
>>>
>>> * *Cable Networks.* With the deployment of the new DOCSIS 3.1 FDX
>>> specifications and its newly defined support for EAP
>>> authentication via X.509 certificate throughout the whole
>>> ecosystem, the ability to provide an EAP-based mechanism that
>>> can be used for credentials provisioning and renewal, would
>>> greately improve the feasibility of in-band credentials
>>> deployment also in this case and the possibility to further
>>> secure the infrastructure by allowing for better certificates
>>> management (i.e., renewal, deployment, etc.)
>>>
>>> * *802.1x / WBA / HS2.0.* Also in these ecosystems, the
>>> possibility to provision (and re-provision) dynamically
>>> credentials opens up the possibility for more secure management
>>> of identities. As in the previous use-cases, the management
>>> directly at layer 2 allows for a simple (and extensible :D)
>>> approach to credentials provisioning for devices.
>>>
>>> Therefore, counting the fact that all these ecosystems are looking
>>> at a standardized / common solution to solve the same issue, I think
>>> it is the right time to evaluate the possibility to work on this
>>> important aspect.
>>>
>>> In my opinion, the WG should open up to evaluate the possibility to
>>> work on the standardization of EAP-based provisioning mechanisms
>>> that would allow for easier management options safer life-cycles of
>>> device and subscribers credentials.
>>>
>>> On the need to re-charter, I would like to point out that this type
>>> of work has been done in the past, therefore is not a completely new
>>> territory (i.e., TEAP / EST). What we need now is the possibility to
>>> address (a) the bootstrapping problem, and (b) the need for
>>> supporting additional provisioning protocols that address different
>>> ecosystems (i.e., simpler approaches that can be implemented in
>>> sub-systems like micro-controllers - this would facilitate the
>>> integration of credentials management independent from the
>>> application layer / wifi module / etc.), and (c) the possibility of
>>> defining provisioning protocols that might be used with or without
>>> additional layers (e.g., EAP-tunneling).
>>>
>>> I hope we will have the possibility to work on this important topic
>>> that, IMO, have the possibility to impact many millions of people
>>> around the world and the security of our networks (Cellular, WiFi,
>>> Corporate, and Home).
>>>
>>> Looking forward to a productive discussion!
>>>
>>> Cheers,
>>> Max
>>>
>>> --
>>> Best Regards,
>>> Massimiliano Pala, Ph.D.
>>> OpenCA Labs Director
>>> OpenCA Logo
>>>
>>>
>>> _______________________________________________
>>> Emu mailing list
>>> Emu@ietf.org
>>> https://www.ietf.org/mailman/listinfo/emu
>>
>
--
Best Regards,
Massimiliano Pala, Ph.D.
OpenCA Labs Director
OpenCA Logo
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
