|
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
