SIP Extensions for Network-Asserted Caller Identity and Privacy within

Trusted Networks

<draft-ietf-sip-privacy-04.txt>

Flemming Andreasen (fandreas@cisco.com)

W. Marshall, K. K. Ramakrishnan, E. Miller, G. Russell, B. Beser, M. Mannette, K. Steinbrenner, D. Oran, F. Andreasen, J. Pickens, P. Lalwaney, J. Fellows, D.

Evans, K. Kelly, M. Watson

IETF - March 2002

Draft Status

• Lots of list discussion and off-line comments

• Currently in WG Last Call

Overview of Changes

• Applicability Statement about appropriate use– Within administrative domain or cooperating domains– Draft is for network-asserted identity, not user-asserted

• Anonymity header removed– Issue of IP address privacy still described, but no solution

offered (general service invocation issue)

• Extensions must be documented in an RFC and undergo designated expert review

• Grammar fixes and 2543bis alignment• Various editorial changes

Open Issue #1

• Proxy handling of a Remote-Party-ID received from untrusted entity (proxy or UA)– Option 1

• If verifiable, set “screen=yes”• If not verifiable, set “screen=no”

– Option 2• Always remove untrusted Remote-Party-ID• If identity can be determined, add new Remote-Party-ID with identity

information

– Option 1 more general than option 2• Option 1 allows unsupported identity types to be passed while still

supporting the general privacy handling functions• Option 2 assumes that an untrusted Remote-Party-ID is always useless.

Option 1 lets the user decide

– Recommendation: Option 1

Open Issue #2

• Explicitly indicate the party type (rpi-pty-type) or infer from message– Option 1

• Explicit “calling” and “called” party types

– Option 2• Always infer from message, i.e. “calling” in request and “called”

in response• Deprecate rpi-pty-type

– Option 1 more general than option 2• Allows “calling” and “called” in other messages than requests

and response respectively (European requirement (?))• Allows for other types of party information in the future (related

extensibility issue)

– Recommendation: Option 1

Open Issue #3

• Types of Identity Information (rpi-id-type)– Option 1

• User, Subscriber, and Terminal

– Option 2• User only (inferred)• Deprecate rpi-id-type

– Option 1 more general than option 2• Allows different types of identity information to be conveyed

which could be important for some network based services• Allows for other types of identity information in the future

(related extensibility issue)

– Recommendation: Option 1

Open Issue #4

• Define “privacy” parameter as a general URI parameter or restrict to Remote-Party-ID– Option 1

• Let “privacy” parameter apply only to Remote-Party-ID.

– Option 2• Let “privacy” parameter be a general URI parameter

– Option 2 more general than option 1• Not clear why the UA couldn’t just make other URIs “private”

to begin with

• Significant draft change

– More discussion needed

Open Issue #5

• Extensibility of rpi-pty-type and rpi-id-type– Option 1

• Make them extensible• Require RFC and designated expert review

– Option 2• Do not make them extensible

– Option 1 more general than option 2• Enables use of existing privacy mechanism for new types of

party and identity information in the future• Potential for abuse, however the required designated expert

review can prevent this

– Recommendation: Option 1

Open Issue #6

• Names of rpi-pty-types– Currently “calling” and “called”, however

somewhat misleading– Alternative suggestions welcome

Open Issue #7

• Cryptographically random identifier in From header field– Leftover from 2543– No longer required given From-tag uniqueness

requirement

• Recommendation:– Use “anonymous@localhost” instead