Text for the SIP Location Conveyance Security Consideration Section

Hi James,

Hi Brian,

below you can find a first attempt to update the security consideration
section of

http://tools.ietf.org/html/draft-ietf-sip-location-conveyance-07

Ciao

Hannes

---------------

Security Considerations

Conveyance of geographical location raises privacy concerns,

and depending on use, there may be confidentiality and access control
aspects.

This section lists scenarios with their corresponding security

and privacy considerations.

Conveying Location by Value

UA Alice SIP Proxy UAS-A UAS-B UAS-C

| SIP Message | | | |

|---------------------------->| | | |

| Location (value/body) | |

| |----------------->|

| | |

| SIP Message |

|<-----------------------------------------------|

| |

Figure z: Location by Value

Figure z shows a SIP message that carries an LbyV in the body of the SIP

message.

Conveying a Reference to Location Information

UA Alice SIP Proxy UAS-A UAS-B UAS-C

Location Server

| SIP Message | | | |

|---------------------------->| | | |

| | SIP Message + LbyR |

| |------------------------->|

| | |

| | |

| | Resolve LbyR |

| |<=========================|

| | |

| | PIDF-LO |

| |=========================>|

| | |

| SIP Message |

|<-------------------------------------------------------|

| |

| |

Figure x: Usage Scenario: Proxy adding LbyR

Figure x shows an exchange where a SIP proxy acts as a Location Server
and

attaches a LbyR to the header of the bypassing SIP message. A separate

protocol interaction is needed to resolve the reference to a PIDF-LO.

UA Alice LCS UAS-A UAS-B UAS-C

| Request LbyR | | | |

|---------------------------->| | | |

| LbyR | | | |

|<----------------------------| | | |

| | | | |

| SIP Message including LbyR |

|------------------------------------------------------->|

| | |

| | Resolve LbyR |

| |<=========================|

| | |

| | PIDF-LO |

| |=========================>|

| |

| SIP Message |

|<-------------------------------------------------------|

| |

| |

Figure y: Usage Scenario: End Host adding Reference

Figure y depicts a message exchange where an LbyR was obtained outside
the

SIP protocol exchange, in this case using the Location Configuration
Protocol, and

where the LbyR is attached to the header or the body of the SIP
message.

Security Guidelines

* Determining the Location Recipient

An end point should know whether location information (by value or by
reference) will be used for location-based routing or for consumption
by the other communication end point. This applies to Figure x, y and
z. When location information is meant for consumption by the other
communication end point only then the usage of S/MIME is RECOMMENDED to
protect the LbyV and LbyR against eavesdropping. The values MUST be
placed into the body of the message. Alternatively, in some
environments hop-by-hop security using TLS MAY provide sufficient
security protection (depending on the location-based application).

Since retargeting and forking might prevent the communication initiator
to obtain the correct public key it is suggested to convey the LbyV /
LbyR after the initial communication setup, for example, using an
UPDATE message. To simplify the management of certificates the usage of
SIP CERT is suggested, see [I-D.ietf-sip-cert].

For cases where location-based routing is envisioned S/MIME cannot be
used since the entity performing the location based routing interaction
is likely not to be known in advance. Hence, TLS MUST be used to
protect the LO in transit.

In cases where a proxy adds an LbyR TLS MUST be used from the SIP proxy
towards the final recipient.

* Computing a LbyR

To prevent others from accessing the LbyR for a particular entity, the
reference to a Location Object MUST NOT be

guessable. It is RECOMMENDED that the reference contains a random
component with at least 128 bit of entropy. For providing randomness
the best current practice guidelines in RFC 4086 [RFC4086] have to be
applied. It is furthermore mandated to use a SIPS URI schema, which
implies the usage of TLS with confidentiality protection, to prevent
eavesdroppers to observe the protocol exchange between the Location
Recipient and the Location Server when dereferencing the LbyR.

These recommendations refer only to Figure x where the SIP proxy adds
the reference to the outgoing message. With the scenario in Figure y
the acquisition of the LbyR and subsequent conveyance is decoupled and
hence it is the responsibility of the LCP specification and ultimately
of the LCS to provide a reference with the same randomness.

It is not necessary to digitally sign the PIDF-LO since authentication
of Location Server is provided by the dereferencing protocol.

* Content of the PIDF-LO

The PIDF-LO contains identity information and privacy rules. In cases
where the end host adds a the PIDF-LO the content of the identity and
the rules conveyed to the Location Recipient are under full control by
the end point itself. However, when a SIP proxy adds a reference to
location information it needs to guess the context. There are, however,
a few information elements in the SIP message itself that provide hint
about the desirable behavior by the SIP proxy.

When SIP privacy mechanisms, see RFC 3323, are used then the PIDF-LO
MUST NOT contain the identity of Target in the entity field of the PIDF
document. Furthermore, the extended privacy rules and the Note Well
statement MUST NOT provide linkability with the identity of the Target.

When the SIP proxy adds a LbyR and does not know the privacy policies
of the Target then it MUST set to the values to the following values:

* The note-well element MUST NOT contain human readable privacy
policies.

* The retransmission-allowed element is set to zero (0), i.e., further
distribution

is not allowed.

* The retention-expires field MUST be set to a maximum of 24 hours.

* The extended policy rules MUST not be present.

* The entity field in the PIDF document MUST be empty.

This document does not provide information how the current context of
the communication initiator is determined other than by inspecting
information provided by RFC 3323 and implicitly via the Service URN
[I-D.ietf-ecrit-service-urn]. At the time of writing this specification
this functionality is made available within the SIP SAML
[I-D.ietf-sip-saml] specification.

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email protected] for questions on current sip
Use [email protected] for new developments on the application of sip