[Ecrit] [ecrit] #16: Re-organization of Section 3.1

["ecrit issue tracker" <[e-mail]>]

#16: Re-organization of Section 3.1

 Material relating to location swapping is currently contained in various
 places in the document.  The proposal is to consolidate this into Section
 3.1, and also include more detail relating to how to address the location
 swapping threat via location signing. Proposal is to change the text of
 Section 3.1 to the following:

 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.  A
    straw-man proposal for location signing is provided in "Digital
    Signature Methods for Location Dependability" [I-D.thomson-geopriv-
    location-dependability].

    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.


                 +-----------+               +-----------+
                 |           |               | 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, [I.D.thomson-geopriv-location-
    dependability] proposes the addition of a "validity" element to the
    PIDF-LO, including a "from" sub-element containing the time that
    location information was validated by the signer, as well as an
    "until" sub-element containing the last time that the signature can
    be considered valid.

    One of the consequences of including an "until" element is that even
    a stationary target would need to periodically obtain a fresh PIDF-
    LO, or incur the additional delay of querying during an emergency
    call.

    Although privacy-preserving procedures may be disabled for emergency
    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.

    Also, the device referred to in the PIDF-LO may not necessarily be
    the same entity conveying the PIDF-LO to the PSAP.  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.

    Without the ability to tie the target identity to the identity
    asserted in the SIP message, it is possible for an attacker to cut
    and paste a PIDF-LO obtained by a different device or user into a SIP
    INVITE and send this to the PSAP.  This cut and paste attack could
    succeed even when a PIDF-LO is signed, or [RFC4474] is implemented.

    To address location-swapping attacks, [I-D.thomson-geopriv-location-
    dependability] proposes addition of an "identity" element which could
    include a SIP URI (enabling comparison against the identity asserted
    in the SIP headers) or an X.509v3 certificate.  If the target was
    authenticated by the LIS, an "authenticated" attribute is added.
    However, inclusion of an "identity" attribute could enable location
    tracking, so that a "hash" element is also proposed which could
    contain a hash of the content of the "identity" element instead.  In
    practice, such a hash would not be much better for real-time
    validation than a pseudonym.

    Location signing is unlikely to deter attacks launched by bot-nets,
    since the work required to verify the location signature is
    considerable.  However, 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.

    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.

    [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 how they would compare to requirements for
    issuance of other certificates such as an SSL/TLS web certificate.

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

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