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 <mohit.m.se...@ericsson.com
<mailto:mohit.m.se...@ericsson.com>> 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
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
_______________________________________________
Emu mailing list
Emu@ietf.org <mailto: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
--
Best Regards,
Massimiliano Pala, Ph.D.
OpenCA Labs Director
OpenCA Logo
_______________________________________________
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu