Hi Bernard,
thanks for your input. Please find a few more thoughts below:
Bernard Aboba wrote:
It is not clear to me whether the requirements do in fact prohibit
server-side authentication. As you note, without server-side
authentication man-in-the-middle attacks are possible; however, even
with server-side authentication, additional requirements may need to
be imposed in order to provide the desired level of security.
I also believe that the requirements does not rule out server-side
authentication.
Requirement #1 is "No Pre-configured trust relationship". This could
refer to pre-configuration of the server with respect to the expected
client credential (PSK or certificate), or it could refer to
pre-configuration of the client with respect to the server, (such
trust anchors). The text seems focused on the former more than the
latter. Assuming that clients can be pre-configured with trust
anchors, then TLS-based EAP methods could meet the requirement.
I agree that this aspect of no pre-configured trust relationship is
quite likely to refer to pre-established shared secrets.
Requirement #2 is "Small" number of messages. While this requirement
clearly excludes long exchanges, it is not clear to me that TLS-based
methods are excluded, particularly if the method is to be implemented
on the AP itself, which potentially would result in lower round-trip
times and eliminate the possibility of AAA-based frame loss.
I doubt that the performance argument counts a lot here given that the
exchange is, as you indicated, local.
It may be possible that requirements #1 and #2 are compatible with
proposals involving unauthenticated client access combined with server
authentication. However, due to lack of a pre-configured network
access profile, this scenario presents additional threats that are
worthy of further discussion.
The presentation refers to the desire to for confidentiality
(presumably at L2, rather than using SRTP). Where confidentiality is
desirable, it will also presumably be important for the client to
determine that it has connected to a legitimate network.
Whereby "legitimate network" is already a quite difficult requirement.
Where a pre-configured network access profile exists, the binding
between a validated server certificate and an advertised SSID is
pre-configured. However, where there is no pre-configured network
access profile, the binding may be difficult to establish without
imposition of additional requirements.
For example, the server certificate/SSID binding cannot be determined
solely via verification of the server certificate. An attacker could
obtain a valid server certificate for "example.com"; does this entitle
them to advertise an SSID of "Emergency Network" or even "Example"?
Since SSIDs are not globally unique, there is no verifiable mapping
between a Server-Id and an allowed set of SSIDs. In general, a CA has
no way of determining whether a server has the rights to a particular
SSID or not, so that a CA cannot in practice vouch for an RFC 4334
SSID extension within a server certificate.
Therefore verification of a binding between the server identity and
the advertised network would only seem to be possible by requiring the
advertised network name to match the Server-Id advertised in the
server certificate. This in turn would require restricting the
allowable SSIDs, or adding another field to the IEEE 802.11
Beacon/Probe Response.
I don't think it make a lot of sense to bind the certificate to the
advertised SSID.
WHAT CAN YOU ACCOMPLISH WITH SERVER-SIDE AUTHENTICATION?
The important question here, I believe, is what you would do with
server-side authentication in such a context given that it has entirely
different semantic than the server-side authentication that is typically
exercised in EAP exchanges between the peer and the EAP server in the
user's home network.
I don't think that addressing man-in-the-middle attacks is the main
objective. Instead, I could imagine that when something goes wrong then
the end user might be able to indicate that he or she was interacting
with a specific network.I see this more as a "debugging" tool.
When some verification steps fails, for example because the certificate
of the server is expired, then in an emergency situation you will just
continue rather than dropping the conversation. Additionally, everyone
should be able to setup networks and hence the adversary can easily do
the same. What would the network of an adversary differentiate from one
that is from someone else?
WHAT ASSUMPTIONS DO WE MAKE WITH RESPECT TO THE SERVER'S CERTIFICATE AND
THE TRUST ANCHORS?
Do we assume that persons that setup networks, such as my home network,
a coffee shop, the IETF network, have to obtain a certificate for their
network from
a) from any company that sells certs typically found in web servers
b) from a dedicated emergency services provider
(Note1)
May I re-use existing trust anchors, such as those available with my web
browsers, or do end devices need to add new root certs into their
certificate store?
In case (b) can I assume that the PSAP also uses the same trust anchor
so that I could potentially use DTLS-SRTP for end-to-end media security
to ensure that I am actually speaking to a real PSAP rather than to an
adversary?
Ciao
Hannes
Note 1: Would it be allowed to just skip server-side authentication and
to end-up with a unauthenticated Diffie-Helman exchange? One might argue
that this does not provide a lot of advantages and we could also skip
the EAP exchange entirely but that's not completely true that
architectures, such as Wimax, assume that keying material is exported
during network attachment and that these keys are used for other
protocols. Hence, if one would change then the impact for the other work
done before would be too large.
From: "Joseph Salowey (jsalowey)" <[EMAIL PROTECTED]>
To: <emu@ietf.org>
CC: <[EMAIL PROTECTED]>, "Bernard Aboba"
<[EMAIL PROTECTED]>
Subject: Draft liaison response for IEEE 802.11u EAP method for
emergency calls
Date: Sun, 16 Sep 2007 22:26:36 -0700
The EMU working group has a liaison request from IEEE 802.11u on EAP
methods for emergency calls. The liaison request can be found on the
liaison statement page, https://datatracker.ietf.org/liaison/ (May
2007). We had a presentations and discussion of this topic at the
Chicago EMU meeting. Below is a draft response based on the discussion
in the meeting. It would be good to have comments on or approval of the
text by Monday, October 1, so a revised response can be created to be
sent as a response to the IEEE.
==============================================================
802.11u Liaison response for EAP Methods for Emergency Communications
We have had discussion of EAP method for Emergency services at the last
IETF meeting in Chicago. The following is a summary of working group
discussion on this topic.
Currently there are no standards track EAP methods that meet the
requirements as understood by the EMU working group. There are several
possible candidates of existing EAP methods that may meet or be slightly
modified to meet some of the 802.11u requirements for emergency
services, especially if minimal latency is not the strongest
requirement. TTLS (draft-funk-eap-ttls-v0-01.txt) and EAP-FAST
(RFC4851) are TLS based methods that can support server only
authentication. It was also pointed out that EAP-TLS
(draft-simon-emu-rfc2716bis-11.txt) could be modified to create a new
EAP method that only requires server side authentication. In order to
truly support emergency services these methods would need to forego
server certificate validation which negates much of the security they
provide by allowing man-in-the-middle attacks. These TLS based methods
also require a significant number of round trips that may not be
acceptable for emergency communication.
There were also several questions raised in the working group during the
discussion that might help in further determining the best approach.
These are summarized below:
1) It is not clear how to make the tradeoff between security and
low-latency. If there is not existing trust relationship there are
limits as to what security properties can be provided. What security
properties are desirable and what is the tolerance for extra-round trips
for the communication?
2) PSK was described as having worse DOS resistance properties that EAP.
It seems that in many cases EAP would have worse DOS resistance that
PSK, which cases is EAP better?
3) It seems that most public access networks already provide an open
access network, why couldn't this network be used for emergency
communication?
4) What regulatory requirements are driving the need for encryption?
This creates some conflicts because encryption without authentication
does not satisfy most useful security requirements.
As the 802.11u group is certainly aware, there are other groups within
the IETF that are looking at unauthenticated emergency services. In
particular, the ECRIT group within the IETF has ongoing work in this
area:
http://tools.ietf.org/html/draft-schulzrinne-ecrit-unauthenticated-acces
s-00
We encourage IEEE working group members to continue the discussion with
the IETF in the EMU and the ECRIT working groups.
_______________________________________________
Emu mailing list
Emu@ietf.org
https://www1.ietf.org/mailman/listinfo/emu
