Subject: [Ecrit] [ecrit] #11: Solutions

From: "ecrit issue tracker" <[email-masked]>
Date: Thu, 28 Feb 2013 04:13:42 -0000

#11: Solutions

 As Brian Rosen has noted, the draft does not reflect our best and current
 thinking about proposed solutions.

-- 
-------------------------------------+-------------------------------------
 Reporter:                           |      Owner:  draft-ietf-ecrit-
  [email-masked]          |  [email-masked]
     Type:  defect                   |     Status:  new
 Priority:  blocker                  |  Milestone:  milestone1
Component:  trustworthy-location     |    Version:  1.0
 Severity:  Active WG Document       |   Keywords:
-------------------------------------+-------------------------------------

Ticket URL: <https://wiki.tools.ietf.org/wg/ecrit/trac/ticket/11>
ecrit <http://tools.ietf.org/ecrit/>

---

From: "ecrit issue tracker" <[email-masked]>
Date: Thu, 28 Feb 2013 04:20:28 -0000

#11: Solutions

Comment (by [email-masked]):

 Here is a proposed replacement for the solutions section:

 3.  Solutions

    This section presents three mechanisms which can be used to convey
    location: signed location by value (Section 4.1), location by
    reference (Section 4.2) and proxy added location (Section 4.3).  In
    addition, this section discusses mechanisms for location trust
    assessment (Section 4.4).

    In order for to provide authentication and integrity protection for
    the SIP messages conveying location, several security approaches are
    available.  While it is possible for proxies to use security
    mechanisms such as SIP Identity [RFC4474] to ensure that
    modifications to the location in transit can be detected by the
    location recipient (e.g., the PSAP), compatibility with Session
    Border Controllers (SBCs) that modify integrity-protected headers has
    proven to be an issue in practice.  As a result, the use of SIP over
    TLS is at present a more likely mechanism to provide per-message
    authentication and integrity protection.

 3.1.  Signed Location by Value

    With location signing, a location server signs the location
    information before it is sent to the end host, (the entity subject to
    the location determination process).

    The signed location information is then verified by the location
    recipient and not by the target.  Figure 1 shows the communication
    model with the target requesting signed location in step (a), the
    location server returns it in step (b) and it is then conveyed to the
    location recipient in step (c) who verifies it.  For SIP, the
    procedures described in RFC 6442 [RFC6442] are applicable for
    location conveyance.

                 +-----------+               +-----------+
                 |           |               | Location  |
                 |    LIS    |               | Recipient |
                 |           |               |           |
                 +-+-------+-+               +----+------+
                   ^       |                    --^
                   |       |                  --
     Geopriv       |Req.   |                --
     Location      |Signed |Signed        -- Geopriv
     Configuration |Loc.   |Loc.        --   Using Protocol
     Protocol      |(a)    |(b)       --     (e.g., SIP)
                   |       v        --       (c)
                 +-+-------+-+    --
                 | Target /  |  --
                 | End Host  +
                 |           |
                 +-----------+

                         Figure 1: Location Signing

    In order to limit replay attacks, additional information, such as
    timestamps or expiration times, has to be included together with the
    signed location.  If the location is retrieved from a location
    server, even a stationary end host has to periodically obtain a fresh
    signed location, or incur the additional delay of querying during the
    emergency call.

    While bot-nets are unlikely to be deterred by location signing,
    accurate location information would limit the subset of the bot-net
    that could be used for an attack, as only hosts within the PSAP
    serving area would be useful in placing emergency calls.

    To prevent location-swapping attacks it is necessary to include some
    some target-specific identity information.  The required information
    depends on whether the goal is real-time verification by the location
    recipient or post-mortem analysis (where the goal is determination of
    the legal entity responsible for the attack).  As argued in Section
    3.4, real-time verification is difficult.

    Location signing is unlikely to deter attacks launched by bot-nets,
    since the work required to verify the location signature is
    considerable.  Location signing is also difficult when the host
    obtains location via mechanisms such as GPS, unless trusted computing
    approaches, with tamper-proof GPS modules, can be applied.
    Otherwise, an end-host can pretend to have a GPS device, and the
    recipient will need to rely on its ability to assess the level of
    trust that should be placed in the endhost location claim.

    A straw-man proposal for location signing is provided in [I-
    D.thomson-geopriv-location-dependability], and [NENA-i2] Section 3.7
    includes operational recommendations relating to location signing:

       Location determination is out of scope for NENA, but we can offer
       guidance on what should be considered when designing mechanisms to
       report location:

       1.  The location object should be digitally signed.

       2.  The certificate for the signer (LIS operator) should be
           rooted in VESA.  For this purpose, VPC and ERDB operators
           should issue certs to LIS operators.

       3.  The signature should include a timestamp.

       4.  Where possible, the Location Object should be refreshed
           periodically, with the signature (and thus the timestamp)
           being refreshed as a consequence.

       5.  Anti-spoofing mechanisms should be applied to the Location
           Reporting method.

       [Note:  The term Valid Emergency Services Authority (VESA) refers
       to the root certificate authority.]

    As noted above, signing of location objects implies the development
    of a trust hierarchy that would enable a certificate chain provided
    by the LIS operator to be verified by the PSAP.  Rooting the trust
    hierarchy in VESA can be accomplished either by having the VESA
    directly sign the LIS certificates, or by the creation of
    intermediate CAs certified by the VESA, which will then issue
    certificates to the LIS.  In terms of the workload imposed on the
    VESA, the latter approach is highly preferable.  However, this raises
    the question of who would operate the intermediate CAs and what the
    expectations would be.

    In particular, the question arises as to the requirements for LIS
    certificate issuance, and whether they are significantly different
    from say, requirements for issuance of an SSL/TLS web certificate.

 3.2.  Location by Reference

    Location-by-reference was developed so that end hosts can avoid
    having to periodically query the location server for up- to-date
    location information in a mobile environment.  Additionally, if
    operators do not want to disclose location information to the end
    host without charging them, location-by-reference provides a
    reasonable alternative.  As noted in RFC 6753 [RFC6753], a location
    reference can be obtained via HTTP-Enabled Location Delivery (HELD)
    [RFC5985] or the Dynamic Host Configuration Protocol (DHCP) location
    URI option [DHCP-URI-OPT].

    Figure 2 shows the communication model with the target requesting a
    location reference in step (a), the location server returns the
    reference in step (b), and it is then conveyed to the location
    recipient in step (c).  The location recipient needs to resolve the
    reference with a request in step (d).  Finally, location information
    is returned to the Location Recipient afterwards.  For location
    conveyance in SIP, the procedures described in [RFC6442] are
    applicable.

                 +-----------+  Geopriv      +-----------+
                 |           |  Location     | Location  |
                 |    LIS    +<------------->+ Recipient |
                 |           | Dereferencing |           |
                 +-+-------+-+ Protocol (d)  +----+------+
                   ^       |                    --^
                   |       |                  --
     Geopriv       |Req.   |                --
     Location      |LbyR   |LbyR          -- Geopriv
     Configuration |(a)    |(b)         --   Using Protocol
     Protocol      |       |          --     (e.g., SIP)
                   |       V        --       (c)
                 +-+-------+-+    --
                 | Target /  |  --
                 | End Host  +
                 |           |
                 +-----------+

                       Figure 2: Location by Reference

    Where location by reference is provided, the recipient needs to
    deference the LbyR in order to obtain location.  The details for the
    dereferencing operations vary with the type of reference, such as a
    HTTP, HTTPS, SIP, SIPS URI or a SIP presence URI.

    For location-by-reference, the location server needs to maintain one
    or several URIs for each target, timing out these URIs after a
    certain amount of time.  References need to expire to prevent the
    recipient of such a URL from being able to permanently track a host
    and to offer garbage collection functionality for the location
    server.

    Off-path adversaries must be prevented from obtaining the target's
    location.  The reference contains a randomized component that
    prevents third parties from guessing it.  When the location recipient
    fetches up-to-date location information from the location server, it
    can also be assured that the location information is fresh and not
    replayed.  However, this does not address location swapping.

    With respect to the security of the de-reference operation, [RFC6753]
    Section 6 states:

       TLS MUST be used for dereferencing location URIs unless
       confidentiality and integrity are provided by some other
       mechanism, as discussed in Section 3.  Location Recipients MUST
       authenticate the host identity using the domain name included in
       the location URI, using the procedure described in Section 3.1 of
       [RFC2818].  Local policy determines what a Location Recipient does
       if authentication fails or cannot be attempted.

       The authorization by possession model (Section 4.1) further relies
       on TLS when transmitting the location URI to protect the secrecy
       of the URI.  Possession of such a URI implies the same privacy
       considerations as possession of the PIDF-LO document that the URI
       references.

       Location URIs MUST only be disclosed to authorized Location
       Recipients.  The GEOPRIV architecture [RFC6280] designates the
       Rule Maker to authorize disclosure of the URI.

       Protection of the location URI is necessary, since the policy
       attached to such a location URI permits anyone who has the URI to
       view the associated location information.  This aspect of security
       is covered in more detail in the specification of location
       conveyance protocols, such as [RFC6442].

    For authorizing access to location-by-reference, two authorization
    models were developed: "Authorization by Possession" and
    "Authorization via Access Control Lists".  With respect to
    "Authorization by Possession" [RFC6753] Section 4.1 notes:

       In this model, possession -- or knowledge -- of the location URI
       is used to control access to location information.  A location URI
       might be constructed such that it is hard to guess (see C8 of
       [RFC5808]), and the set of entities that it is disclosed to can be
       limited.  The only authentication this would require by the LS is
       evidence of possession of the URI.  The LS could immediately
       authorize any request that indicates this URI.

       Authorization by possession does not require direct interaction
       with Rule Maker; it is assumed that the Rule Maker is able to
       exert control over the distribution of the location URI.
       Therefore, the LIS can operate with limited policy input from a
       Rule Maker.

       Limited disclosure is an important aspect of this authorization
       model.  The location URI is a secret; therefore, ensuring that
       adversaries are not able to acquire this information is paramount.
       Encryption, such as might be offered by TLS [RFC5246] or S/MIME
       [RFC5751], protects the information from eavesdroppers.

       Using possession as a basis for authorization means that, once
       granted, authorization cannot be easily revoked.  Cancellation of
       a location URI ensures that legitimate users are also affected;
       application of additional policy is theoretically possible but
       could be technically infeasible.  Expiration of location URIs
       limits the usable time for a location URI, requiring that an
       attacker continue o learn new location URIs to retain access to
       current location information.

    In situations where "Authorization by Possession" is not suitable
    (such as where location hiding [RFC6444] is required), the
    "Authorization via Access Control Lists" model may be preferred.

    Without the introduction of hierarchy, it would be necessary for the
    PSAP to manage client certificates or Digest credentials for all the
    LISes in its coverage area, to enable it to successfully dereference
    LbyRs.  However, while PIDF-LO signing credentials are provided to
    the LIS operator and can be validated by the PSAP using the VESA
    trust anchor, in the case of de-referencing, without hierarchy the
    PSAP would need to obtain credentials for each LIS.  As a result,
    without the introduction of hierarchy, the operational considerations
    of "Authorization via Access Control Lists" are more formidable than
    validation of signed PIDF-LOs.

    As with PIDF-LO signing, the operational issues of LbyR can be
    addressed to some extent by introduction of hierarchy.  Rather than
    requiring the PSAP to obtain credentials for accessing each LIS, the
    local LIS could be required to upload location information to
    location aggregation points who would in turn manage the
    relationships with the PSAP.  This would shift the management burden
    from the PSAPs to the location aggregation points.

 3.3.  Proxy Adding Location

    Instead of relying upon the endhost to provide location, is possible
    for a proxy that has the ability to determine the location of the end
    point (e.g., based on the endhost IP or MAC address) to retrieve and
    add or override location information.

    The use of proxy-added location is primarily applicable in scenarios
    where the endhost does not provide location.  As noted in [RFC6442]
    Section 4.1:

       A SIP intermediary SHOULD NOT add location to a SIP request that
       already contains location.  This will quite often lead to
       confusion within LRs.  However, if a SIP intermediary adds
       location, even if location was not previously present in a SIP
       request, that SIP intermediary is fully responsible for addressing
       the concerns of any 424 (Bad Location Information) SIP response it
       receives about this location addition and MUST NOT pass on
       (upstream) the 424 response.  A SIP intermediary that adds a
       locationValue MUST position the new locationValue as the last
       locationValue within the Geolocation header field of the SIP
       request.

       A SIP intermediary MAY add a Geolocation header field if one is
       not present -- for example, when a user agent does not support the
       Geolocation mechanism but their outbound proxy does and knows the
       Target's location, or any of a number of other use cases (see
       Section 3).

    As noted in [RFC6442] Section 3.3:

       This document takes a "you break it, you bought it" approach to
       dealing with second locations placed into a SIP request by an
       intermediary entity.  That entity becomes completely responsible
       for all location within that SIP request (more on this in Section
       4).

    While it is possible for the proxy to override location included by
    the endhost, [RFC6442] Section 3.4 notes the operational limitations:

       Overriding location information provided by the user requires a
       deployment where an intermediary necessarily knows better than an
       end user -- after all, it could be that Alice has an on-board GPS,
       and the SIP intermediary only knows her nearest cell tower.  Which
       is more accurate location information? Currently, there is no way
       to tell which entity is more accurate or which is wrong, for that
       matter.  This document will not specify how to indicate which
       location is more accurate than another.

    The disadvantage of this approach is the need to deploy application
    layer entities, such as SIP proxies, at AIPs or associated with AIPs.
    This requires a standardized VoIP profile to be deployed at every end
    device and at every AIP.  This might impose interoperability
    challenges.

    Additionally, the AIP needs to take responsibility for emergency
    calls, even for customers they have no direct or indirect
    relationship with.  To provide identity information about the
    emergency caller from the VSP it would be necessary to let the AIP
    and the VSP to interact for authentication (see, for example,
    [RFC4740]).  This interaction along the Authentication, Authorization
    and Accounting infrastructure is often based on business
    relationships between the involved entities.  The AIP and the VSP are
    very likely to have no such business relationship, particularly when
    talking about an arbitrary VSP somewhere on the Internet.  In case
    that the interaction between the AIP and the VSP fails due to the
    lack of a business relationship then typically a fall-back would be
    provided where no emergency caller identity information is made
    available to the PSAP and the emergency call still has to be
    completed.

 3.4.  Location Trust Assessment

    Where location is not inherently trustworthy (such as where location-
    by-value is used without location signing), it still may be possible
    to assess the level of trustworthiness of the conveyed location
    information.

    For real-time validation, information in the signaling and media
    packets can be cross checked against location information.  For
    example, it may be possible to determine the region associated with
    the IP address included within SIP Via: or Contact: headers, or the
    media source address, and compare this against the location
    information reported by the caller or conveyed in the PIDF-LO.  While
    a a CAPTCHA-style test may be applied to suspicious calls to lower
    the risk from bot-nets, this is quite controversial for emergency
    services, due to the risk of delaying or rejecting valid calls.

    By design, PIDF-LO objects limit the information available for real-
    time attribution,.  As noted in [RFC5985] Section 6.6:

       The LIS MUST NOT include any means of identifying the Device in
       the PIDF-LO unless it is able to verify that the identifier is
       correct and inclusion of identity is expressly permitted by a Rule
       Maker.  Therefore, PIDF parameters that contain identity are
       either omitted or contain unlinked pseudonyms [RFC3693].  A
       unique, unlinked presentity URI SHOULD be generated by the LIS for
       the mandatory presence "entity" attribute of the PIDF document.
       Optional parameters such as the "contact" and "deviceID" elements
       [RFC4479] are not used.

    As a result, typically the location recipient will be unable to
    verify in real-time whether the entity on whose behalf location was
    determined represents the same entity conveying location to the
    recipient.  This is true even where "Enhancements for Authenticated
    Identity Management in the Session Initiation Protocol (SIP)"
    [RFC4474] is used, allowing the recipient to verify the identity
    assertion in the From: header.

    The lack of binding between the entity obtaining the PIDF-LO and the
    entity conveying the PIDF-LO to the recipient enables cut and paste
    attacks which would enable an attacker to assert a bogus location,
    even where both the SIP message and PIDF-LO are signed.  As a result,
    even implementation of both [RFC4474] and location signing does not
    guarantee that location can be tied to a specific endpoint in real-
    time.  As noted in [RFC6442] Section 1:

       In no way does this document assume that the SIP user agent client
       that sends a request containing a location object is necessarily
       the Target.  The location of a Target conveyed within SIP
       typically corresponds to that of a device controlled by the
       Target, for example, a mobile phone, but such devices can be
       separated from their owners, and moreover, in some cases, the user
       agent may not know its own location.

    However, although real-time validation based on PIDF-LO elements is
    challenging, where LIS audit logs are available (such as where a law
    enforcement agency can present a subpoena), linking of a pseudonym to
    the device obtaining location can be accomplished in a post-mortem.

    Similarly, real-time validation of the timestamp contained within
    PIDF-LO objects (reflecting the time at which the location was
    determined) is challenging.  Even if the PIDF-LO is signed the
    timestamp only represents an assertion by the LIS, which may or may
    not be trustworthy.  For example, the recipient of the signed PIDF-LO
    may not know whether the LIS supports time synchronization, or
    whether it is possible to reset the LIS clock manually without
    detection.  Even if the timestamp was valid at the time location was
    determined, a time period may elapse between when the PIDF-LO was
    provided and when it is conveyed to the recipient.  Periodically
    refreshing location information to renew the timestamp even though
    the location information itself is unchanged puts additional load on
    LISes.  As a result, recipients need to validate the timestamp in
    order to determine whether it is credible.

 Severity:  Active WG Document       |  Resolution:
 Keywords:                           |

Ticket URL: <http://trac.tools.ietf.org/wg/ecrit/trac/ticket/11#comment:1>
ecrit <http://tools.ietf.org/ecrit/>

---

From: "ecrit issue tracker" <[email-masked]>
Date: Thu, 28 Feb 2013 22:29:04 -0000

#11: Solutions

 Another revision below:

 3.  Solutions

    The signed location information is then verified by the location
    recipient and not by the target.  Figure 1 shows the communication
    model with the target requesting signed location in step (a), the
    location server returns it in step (b) and it is then conveyed to the
    location recipient in step (c) who verifies it.  For SIP, the
    procedures described in "Location Conveyance for the Session
    Initiation Protocol" [RFC6442] are applicable for location
    conveyance.

    3.4, real-time verification is not always possible.

    Location signing is unlikely to deter attacks launched by bot-nets,
    since the work required to verify the location signature is
    considerable.  Location signing is also difficult when the host
    obtains location via mechanisms such as GPS, unless trusted computing
    approaches, with tamper-proof GPS modules, can be applied.
    Otherwise, an end host can pretend to have a GPS device, and the
    recipient will need to rely on its ability to assess the level of
    trust that should be placed in the end host location claim.

    reasonable alternative.  As noted in "A Location Dereference Protocol
    Using HTTP-Enabled Location Delivery (HELD)" [RFC6753], a location

    Instead of relying upon the end host to provide location, is possible
    for a proxy that has the ability to determine the location of the end
    point (e.g., based on the end host IP or MAC address) to retrieve and
    add or override location information.

    The use of proxy-added location is primarily applicable in scenarios
    where the end host does not provide location.  As noted in [RFC6442]
    Section 4.1:

    While it is possible for the proxy to override location included by
    the end host, [RFC6442] Section 3.4 notes the operational
    limitations:

    The ability to assess the level of trustworthiness of conveyed
    location information is important, since this makes it possible to
    understand how much value should be placed on location information,
    as part of the decision making process.  As an example, if automated
    location information is understood to be highly suspect, a call taker
    can put more effort into obtaining location information from the
    caller.

    Caller accountability is another important aspect of trust
    assessment.  Can the individual purchasing the device or activating
    service be identified or did the call originate from a non-service
    initialized (NSI) device whose owner cannot be determined?  Prior to
    the call, was the caller authenticated at the network or application
    layer?  In the event of a prank call, can audit logs be made
    available to an investigator, or can information relating to the
    owner of an unlinked pseudonym be provided, enabling investigators to
    unravel the chain of events that lead to the attack?  In practice,
    the ability to identify a caller may decrease the likelihood of
    caller misbehavior.  For example, where emergency calls have been
    allowed from handsets lacking a SIM card, or where ownership of the
    SIM card cannot be determined, the frequency of nuisance calls has
    often been unacceptably high [TASMANIA][UK][SA].

    Note that location trust assessment has value regardless of whether
    the location has been conveyed securely (via signed location,
    location-by-reference or proxy-added location) or not (via location-
    by-value without location signing), since secure conveyance does not
    provide assurance relating to the validity or provenance of location
    data.

    In practice, the source of the location data is important for
    location trust assessment.  For example, location provided by a
    Location Information Server (LIS) whose administrator has an
    established history of meeting emergency location accuracy
    requirements (e.g. Phase II) may be considered more reliable than
    location information provided by a third party Location Service
    Provider (LSP) that disclaims use of location information for
    emergency purposes.

    However, even where an LSP does not attempt to meet the accuracy
    requirements for emergency location, it still may be able to provide
    information useful in assessing about how reliable location
    information is likely to be.  For example,  was location determined
    based on the nearest cell tower or 802.11 Access Point (AP), or was a
    triangulation method used?  If based on cell tower or AP location
    data, was the information obtained from an authoritative source (e.g.
    the tower or AP owner) and when was the last time that the location
    of the tower or access point was verified?

    The lack of binding between the entity obtaining the PIDF-LO and the
    entity conveying the PIDF-LO to the recipient enables cut and paste
    attacks which would enable an attacker to assert a bogus location,
    even where both the SIP message and PIDF-LO are signed.  As a result,
    even implementation of both "Enhancements for Authenticated Identity
    Management in the Session Initiation Protocol (SIP)" [RFC4474] and
    location signing does not guarantee that location can be tied to a
    specific endpoint in real-time.  As noted in [RFC6442] Section 1:

Ticket URL: <https://svn.tools.ietf.org/wg/ecrit/trac/ticket/11#comment:2>
ecrit <http://tools.ietf.org/ecrit/>

---

From: "ecrit issue tracker" <[email-masked]>
Date: Thu, 28 Feb 2013 22:29:13 -0000

#11: Solutions

Changes (by [email-masked]):

 * status:  new => closed
 * resolution:   => fixed

-- 
-------------------------------------+-------------------------------------
 Reporter:                           |       Owner:  draft-ietf-ecrit-
  [email-masked]          |  [email-masked]
     Type:  defect                   |      Status:  closed
 Priority:  blocker                  |   Milestone:  milestone1
Component:  trustworthy-location     |     Version:  1.0
 Severity:  Active WG Document       |  Resolution:  fixed
 Keywords:                           |
-------------------------------------+-------------------------------------

Ticket URL: <https://trac.tools.ietf.org/wg/ecrit/trac/ticket/11#comment:3>
ecrit <http://tools.ietf.org/ecrit/>