Subject: [Sip] Proposed plan for Network-Asserted ID/Privacy

From: Rohan Mahy <[email-masked]>
Date: Thu, 18 Apr 2002 16:06:40 -0700 (Pacific Daylight Time)

Hi,

I'd like to propose a concrete plan to move forward with a solution for
network-asserted identity and privacy.  I'm proposing this as an
individual (who is sick of reading about this topic on the mailing
list).  Below I've listed some of problems that various folks were
apparently trying to solve in this space.

1.  Provide a Network-Asserted ID
 a.   Within a trusted administrative domain or federation of domains
 b.   For interworking with PSTN mechanisms*
 c.   Usable across administrative boundaries

2.  Provide capability for Call Trace
 a.   Within a trusted administrative domain or federation of domains
 b.   For interworking with PSTN mechanisms*
 c.   Usable across administrative boundaries

3.  Provide privacy
 a.   by the user directly withholding information from the network
 b.   in the network for user-provided info at the user's request
 c.   in the network for user-provided info based on network policy
 d.   of network-provided information

4.  Allow for a user-provided "hint" for Network-Asserted ID

*(with gateways in the trusted domain or federation)

Most of the snags and disagreements we have had with the existing
Remote-Party-ID draft (draft-ietf-sip-privacy-04) are related to problems
1c, 2c, and 4.  Even a very scaled-down version of this draft would allow
for trusted intermediaries and user agents (including gateways) to
exchange network asserted identity and provide the capability for call
trace within a domain or federation of trusted domains.  The solution is
as simple as a single header which carries the identity in clear text,
which is added by the first proxy that authenticates the user, and
removed before it leaves the trust boundary.  This would solve
1a, 1b, 2a, and 2b.

Jon Peterson just drafted a Network-Asserted Identity proposal which
requires S/MIME signatures on each message.  This address the whole
category of problems related to 1 and 2 using cryptographic mechanisms.
While you could use this mechanism inside trusted networks, the
mechanism may be too heavyweight to prove practical for use with every
call in every network.  However, this is the only proposed mechanism
to solve 1c, and 2c in an elegant manner.

Jon also took a stab at the "longer-term" privacy requirements.  His draft
discusses how to solve problems 3a and 3b, and could be extended to
support 3d (as proposed in Jon's identity draft).  In addition, a network
has always been able to introduce an anonymizing B2BUA to solve problem
3c.

Finally, we have problem 4.  Some folks have proposed that
UAs should provide a hint using the same mechanism used to
communicate network asserted identity among trusted entities.
Others propose that authentication servers that create a
network asserted identity accept multiple "usernames" during
authentication and use this as the hint.  AFAIK these are the
only two choices, and we can come up with an answer to this
question in a separate thread.  The answer does not fundamentally
change any of the mechanisms we select to solve the other problems.

So, in summary, I'm proposing:

No additional work is required to implement 3c

Three short term deliverables
I) adopt draft-peterson-sip-privacy-longterm as a WG item to solve
   3a and 3b

II) write an extension to I) as a WG item for requesting privacy of
network asserted ID (however it is expressed) to support 3d.  This would
get used by III and IV.

III) pare down the mechanism in draft-ietf-sip-privacy to only address 1a,
1b, 2a, and 2b.  quickly get closure on which mechanism we use for 4, and
include it in the draft.  keep the current applicability statement.

One or more longer term deliverables, including
IV) draft-peterson-sip-identity ... to address a more general way to
solve 1 and 2 including 1c and 2c.  Note that this draft is the first
step toward providing real cryptographic identity services.  I think we
also need to address this topic as a charter item.

We might also provide an informational document describing how to map
privacy and identity between SIP and the PSTN.

hope this helps.
thanks,
-rohan

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

---

From: Flemming Andreasen <[email-masked]>
Date: Fri, 19 Apr 2002 09:52:42 -0400

Rohan Mahy wrote:

> removed before it leaves the trust boundary.

You need to be more clear. 1 and 2 talk about administrative domains and
administrative boundaries and now you are talking about trust boundaries. How
do you define an administrative domain, an administrative boundary, and a
trust boundary ?

> This would solve

No. The UA is (normally) untrusted but still needs it. If you were only
talking about the case when privacy was requested, then it doesn't address the
requirement to provide call trace for anonymous calls. The user is obviously
untrusted and hence cannot be given the caller-id in clear-text. The privacy
draft solves this by handing out an encrypted Remote-Party-Id which can
subsequently be used for call trace (as well as other features for that
matter, e.g. anonymous call return).

<snip>

> change any of the mechanisms we select to solve the other problems.

Well it certainly impacts it. If you go with the first solution then you also
accept that Remote-Party-Id can be provided by an untrusted entity, so I don't
think we can solve these independently.

> I) adopt draft-peterson-sip-privacy-longterm as a WG item to solve

It's unclear that 3b is independent of which mechanism you choose to provide
the hint above.

> include it in the draft.  keep the current applicability statement.

As mentioned above, I'm not clear on exactly what 1a, 1b, 2a and 2b are, but
if the "network asserted identity" draft would neither address privacy for
network asserted identity, nor call trace for anonymous calls, then I
certainly disagree with this.

-- Flemming