Subject: Re: [Ecrit] Unauthenticated access review -02

From: Bernard Aboba <[email-masked]>
Date: Sun, 10 Jul 2011 16:05:05 -0700

Here is my review. 

Summary
-----------

This document has improved but there are still some major issues. An 
important use case (unauthorized network access) does not appear to be 
covered, and the operational implications of enabling unauthenticated or
 unauthorized emergency access have not been explored deeply enough.  My recommendation is that operators be recruited to review this document. 

Specific comments: 

1.  Introduction

   Summoning police, the fire department or an ambulance in emergencies
   is one of the fundamental and most-valued functions of the telephone.
   As telephone functionality moves from circuit-switched telephony to
   Internet telephony, its users rightfully expect that this core
   functionality will continue to work at least as well as it has for
   the older technology.  New devices and services are being made
   available that could be used to make a request for help, which are
   not traditional telephones, and users are increasingly expecting them
   to be used to place emergency calls.

[BA] It would be useful to (briefly) discuss the existing functionality
for emergency calling with Non-Service Initialized (NSI) devices here.

   We distinguish between three conditions:

   No Access Authentication (NAA):  In the NAA case, the emergency
      caller does not posses valid credentials for the access network.
      This includes the case where the access network allows pay-per-
      use, as is common for wireless hotspots, but there is insufficient
      time to enter credit card details and other registration
      information required for access.  It also covers all cases where
      either no credentials are available at all, or the available
      credentials do not work for the given IAP/ISP.  As a result, the
      NAA case basically combines the below NASP and ZBP cases, but at
      the IAP/ISP level.  Support for emergency call handling in the NAA
      case is subject to the local policy of the ISP.  Such policy may
      vary substantially between ISPs and typically depends on external
      factors that are not under the ISP control.

[BA] This does not appear to cover the case of lack of network access 
authorization. For example, a user might have an account, but have 
depleted their prepaid account, or perhaps they are authorized only
for voice, but not data.

   Note: At the time of writing there is no regulation in place that
   demands the functionality described in this memo.  SDOs have started
   their work on this subject in a proactive fashion in the anticipation
   that national regulation will demand it for a subset of network
   environments.

[BA] This should also stated earlier, such in the abstract.

   There are also indications that the functionality of unauthenticated
   emergency calls (called SIM-less calls) in today's cellular system in
   certain countries leads to a fair amount of hoax or test calls.  This
   causes overload situations at PSAPs which is considered harmful to
   the overall availability and reliability of emergency services.

   As an example, Federal Office of Communications (OFCOM, Switzerland)
   provided statistics about emergency (112) calls in Switzerland from
   Jan. 1997 to Nov. 2001.  Switzerland did not offer SIM-less emergency
   calls except for almost a month in July 2000 where a significant
   increase in hoax and test calls was reported.  As a consequence, the
   functionality was disabled again.  More details can be found in the
   panel presentations of the 3rd SDO Emergency Services Workshop
   [esw07].

[BA] I recommend that these paragraphs be moved up earlier, right after
a basic description of NSI functionality.

   Figure 1 compiles the basic logic taking place during network entry
   for requesting an emergency service and shows the interrelation
   between the three conditions described in the above section.

                         +-----Y
                         |Start|
                         `...../
                            |
                            | Are credentials
                            | for network attachment
                            | available?
                            |
               NO           v         YES
             +----------------------------+
             |                            |
             |                            |
             V                            v
        ..............               ................
        | Idle: Wait |               |Execute       |
        | for ES Call|               |LLA Procedures|
        | Initiation |               "--------------'
        "------------'                    |
    Is        |               +---------->O
    emergency |               |           | Is ASP
    service   | NO +-----Y    |           | configured?
    network   +--->| End |    |           +---------------+
    attachment|    `...../    |       YES |               | NO
    possible? |               |           |               |
              v               |           v               v
        +------------+        |     +------------+    +------------+
        | Execute    |        |     | Execute    |    | Execute    |
        | NAA        |--------+     | Phone BCP  |    | NASP       |
        | Procedures |              | Procedures |    | Procedures |
        +------------+              +------------+    +------------+
                         Authorization for|                |
                         Emergency Call?  |                |
                           +--------------+                v
                           | NO           | YES         +-----Y
                           |              |             | Done|
                           v              v             `...../
                    +------------+  +------------+
                    | Execute    |  | Execute    |
                    | ZBP        |  | Phone BCP  |
                    | Procedures |  | Procedures |
                    +------------+  +------------+
                           |              |
                           |              |
                           v              v
                        +-----Y        +-----Y
                        | Done|        | Done|
                        `...../        `...../

   Abbreviations:
     LLA: Link Layer Attachment
     ES: Emergency Services

                          Figure 1: Flow Diagram

[BA] The reality is considerably more complicated that than this. 
For example:

* network access credentials may be available, but not authorization (e.g. depleted prepaid account, no data authorization)

* A Web portal using DNS spoofing might be in place. 

* Firewalls may be in place blocking access to some services (e.g. no UDP/TCP outbound, only HTTP). 

As a result, I'm not convinced that this flowchart is useful enough in its current state.   For example, the case of uanthorized access will result in gong down a unexpected code path.   Even if it is updated it would probably be better to move it to an appendix so as not to interrupt the document flow.  It might even make sense to remove it altogether.

5.1.5.  SIP Emergency Call Signaling

   SIP signaling capabilities [RFC3261] are mandated for end hosts.

   The initial SIP signaling method is an INVITE.  The SIP INVITE
   request MUST be constructed according to the requirements in Section
   9.2 [I-D.ietf-ecrit-phonebcp].

   Regarding callback behavior SIP UAs SHOULD place a globally routable
   URI in a Contact: header.

[BA] SIP UA's can't obtain GRUUs on their own.  Is there an ASP requirement
here? Also, should there be a reference to a PSAP callback document?

5.2.2.  Location Determination and Location Configuration

   The ISP is responsible for location determination and exposes this
   information to the end points via location configuration protocols.
   The considerations described in [I-D.ietf-ecrit-location-hiding-req]
   are applicable to this document.

   The ISP MUST support one of the LCPs described in Section 6.5 of
   [I-D.ietf-ecrit-phonebcp].  The description in Section 6.5 and 6.6 of
   [I-D.ietf-ecrit-phonebcp] regarding the interaction between the end
   device and the LIS applies to this document.

   The interaction between the LIS at the ISP and the IAB is often
   priorietary but the description in
   [I-D.winterbottom-geopriv-lis2lis-req] may be relevant to the reader.

[BA] Don't you mean IAP and not IAB here?

6.2.  Securing Network Attachment in NAA Cases

   2) Null Authentication:

      In one case (e.g.  WiMAX) an EAP method is performed.  However, no
      credentials specific to either the server or the device or
      subscription are used as part of the authentication exchange.  An
      example for this would be an EAP-TLS exchange with using the
      TLS_DH_anon (anonymous) ciphersuite.  

[BA] EAP-TLS [RFC 5216] does not support the negotiation of the anonymous DH
ciphersuite.  At a minimum, the server needs to provide a certificate. 

      Alternatively, a publicly
      available static key for emergency access could be used.  In the
      latter case, the device would need to be provisioned with the
      appropriate emergency key for the IAP/ISP in advance.  In another
      case (e.g.  IEEE 802.11), no EAP method is used, so that empty
      frames are transported during the over the air IEEE 802.1X
      exchange.  In this case the authentication state machine completes
      with no cryptographic keys being exchanged.

[BA] It is not clear what it is being described here.  If WPA2 Enterprise
is used, then EAP and an EAP method will need to be selected.  RFC 3748
does not support exchange of "empty" EAP frames.

7.  Security Considerations

   There are a couple of new vulnerabilities raised with unauthenticated
   emergency services in NASP/NAA cases since the PSAP operator will
   typically not possess any identity information about the emergency
   call via the signaling path itself.  In countries where this
   functionality is used for GSM networks today this has lead to a
   significant amount of misuse.

[BA] I think you need to discuss the NASP and NAA cases separately. 
In the NASP case, the user might have valid credentials with the ASP,
so that the PSAP could obtain identify information.  In the NAA case,
you need to separate unauthenticated from unauthorized access.  In
the former case, there may be no NAI, but there may be other identifying
info (e.g. MAC address).  In the latter case there is an identity. 

   In the context of NAA, the IAP and the ISP will probably want to make
   sure that the claimed emergency caller indeed performs an emergency
   call rather than using the network for other purposes, and thereby
   acting fraudulent by skipping any authentication, authorization and
   accounting procedures.  By restricting access of the unauthenticated
   emergency caller to the LoST server and the PSAP URI, traffic can be
   restricted only to emergency calls.  This can be accomplished with
   traffic separation.  The details, however, e.g. for using filtering,
   depend on the deployed ISP architecture and are beyond the scope of
   this document.

   We only illustrate a possible model.  If the ISP runs its own LoST
   server, it would maintain an access control list including all IP
   addresses contained in responses returned by the LoST server, as well
   as the LoST server itself.  (It may need to translate the domain
   names returned to IP addresses and hope that the resolution captures
   all possible DNS responses.)  Since the media destination addresses
   are not predictable, the ISP also has to provide a SIP outbound proxy
   so that it can determine the media addresses and add those to the
   filter list.

[BA] There are some very challenging operational problems here that you
need to discuss in more depth.  I would recommend that this section 
be reviewed by operators, to ensure that the advice is implementable.
Some concerns:

1. DNS spoofing.  Many 802.11 hotspots use web portals today along
with DNS spoofing.  This will block any emergency calling device 
without a web browser, create delays for those with a browser, and
may cause certificate or DNSSEC validation failures within VOIP
clients. 

2. ISP operation of a SIP outbound proxy configuration.  This doesn't
seem implementable to me.  Getting a naive user to change
their SIP outbound proxy configuration to make an emergency call is
time consuming and likely to consume valuable time in an emergency.
There are SIP clients that will require SIP over TLS and may not
have trust anchors configured for the ISP SIP proxy.  Overall, an
ISP taking this on will be challenged to provide tech support to
non-customers in potentially emergent situations.  Do we really
think this is a viable approach? 

3. Firewall configurations.  
Operators will often have concerns about opening generic holes 
in the firewall (e.g. opening a hole for traffic to destination 
ports 5060/5061).  To ensure that traffic is actually being used 
for emergency purposes, deep packet inspection may be required.  
But what happens if the traffic is encrypted (e.g. SIP over TLS)?

---

From: Bernard Aboba <[email-masked]>
Date: Sun, 10 Jul 2011 19:43:18 -0700

In general, I'd suggest that there are a number of very challenging operational issues within the unauthenticated/unauthorized network access scenario:

a. The state of Hotspot access.  While it's not the job of this document to provide "best practice network engineering" recommendations to hotspot operators, today's realities are sobering. 

Few hotspot networks support Open Access with no web portal, or even WPA/WPA2 in any form (PSK or Enterprise (EAP)). Instead, they typically only allow DNS and HTTP requests prior to feeding the Web portal monsta, and DNS A RR requests are responded to with the address of the portal.  If your device doesn't have a browser, good luck.  If it does have a browser (e.g. a smartphone), feeding the monsta to gain access to the Internet is annoying at best in a normal situation;  in an emergency, it will feel like a twisted game of "Minute to Win It" with a life on the line. The typical Web portal/DNS spoofing installation wreaks havoc with 
applications in a number of ways, so even when you obtain access to the Internet there may be problems.  Prior to feeding the monsta, applications using UDP will lose packets and back off their retransmission timers, causing delays.  Applications  utilizing TLS will be confused by spoofed DNS responses and certificates that may will not match the requested FQDN, resulting in error messages.   Restoring your VOIP application to a less befuddled state may require you to kill and then restart it.

Let's say you get on the network and get your VOIP application up and running so you can call an emergency number.  The typical access point will not support DHCP-based location or LOST configuration as a server (for users who request it) or as a DHCP location client (to obtain location from the upstream provider).   The replacement cycle of hotspot networks is quite long so many of these networks still support IEEE 802.11b (not a, g, or n) and have not been upgraded since the early part of this decade.   If the hotspot operator or their upstream provider does not support HELD, the most likely source of location configuration is probably a location API (like the W3C location API) which will query a "location-based service" (probably a hard-wired service that isn't warranted for emergency use).   So you may not be able to obtain a reliable location 
automatically and may have to enter it manually.  Yet more delays while 
you fumble some more.  

Some recommendations that might help:

1. Support for WPA2 in some form.  Most APs can do this, possibly as a "virtual AP" so that you don't have to make a (likely to be ignored) recommendation to disable the portal monsta, just to provide a way around it to make emergency access more viable.
 
2. Support for DHCP/LoST configuration in the DHCP server built into the AP.  Support for acting as a DHCP location client to the upstream provider to obtain location, or if that fails, making a query to a "location based service".  

b.  The fraud prevention problem.   Assuming that the portal monsta issues are dealt with, the next hurdle is fraud prevention on non-hotspot (e.g. carrier) networks.  In a situation where network access is unauthenticated or unauthorized, it will be challenging to enable access to arbitrary emergency services.  Operators will typically not feel comfortable punching holes in the firewall to allow traffic to flow to a generic source address and a destination port.  Doing deep packet inspection will not be straightforward.  What if the traffic is encrypted (e.g. SIP over TLS)?  Blocking proprietary protocols the DPI device can't decrypt or doesn't understand may not be an option either (for network neutrality or other legal/political reasons).  

My conclusion is that the (only?) viable solution may be for the carrier to run emergency services themselves and provide applications that work with those services on their devices.   However, unless the applications support multiple carriers, this will not solve the problem for roaming devices.   

From: [email-masked]
To: [email-masked]
Date: Sun, 10 Jul 2011 16:05:05 -0700
Subject: Re: [Ecrit] Unauthenticated access review -02

Here is my review. 

Summary
-----------

Specific comments: 

1.  Introduction

                         +-----Y
                         |Start|
                         `...../
                            |
                            | Are credentials
                            | for network attachment
                            | available?
                            |
               NO           v         YES

   Abbreviations:

                          Figure 1: Flow Diagram

   2) Null Authentication:

               		 	   		  

_______________________________________________
Ecrit mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ecrit