Subject: [Ecrit] [ecrit] #7: Review of unauthenticated access document (-02)

From: "ecrit issue tracker" <[email-masked]>
Date: Sun, 10 Jul 2011 22:23:15 -0000

#7: Review of unauthenticated access document (-02)

 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.

 * 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 accurate or useful
 enough to include at the
 beginning of the document.  Better to move it to an appendix or 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 operaton 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)?

-- 
---------------------------------------+------------------------------------
 Reporter:  bernard_aboba@…            |       Owner:  draft-ietf-ecrit-unauthenticated-access@…             
     Type:  defect                     |      Status:  new                                                   
 Priority:  critical                   |   Milestone:  milestone1                                            
Component:  unauthenticated-access     |     Version:  1.0                                                   
 Severity:  Active WG Document         |    Keywords:                                                        
---------------------------------------+------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/ecrit/trac/ticket/7>
ecrit <http://tools.ietf.org/ecrit/>