Hi Mohit,
On 10/24/19 3:30 AM, Mohit Sethi M wrote:
Dear Dr. Pala,
[ ... ]
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.
On 10/24/19 3:11 AM, Dr. Pala wrote:
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
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
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 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
--
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
_______________________________________________
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
