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

From: "Mark Watson"<[email-masked]>
Date: Fri, 19 Apr 2002 10:22:36 +0100

Good plan. I agree.

...Mark

> -----Original Message-----
> From: Rohan Mahy [mailto:[email-masked]]
> Sent: 19 April 2002 00:07
> To: [email-masked]
> Subject: [Sip] Proposed plan for Network-Asserted ID/Privacy
> 
> 
> 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: William Marshall <[email-masked]>
Date: Fri, 19 Apr 2002 15:00:28 -0400 (EDT)

Rohan Mahy wrote:
> I'd like to propose a concrete plan to move forward with a solution for

Once a proxy has determined the value of this "Network-Asserted ID",
there are actually four possibilities to consider.
   a.   Sending it to another proxy within a trusted admin domain 
		or federation of domains
   b.   Sending it to a PSTN gateway within a trusted admin domain
		or federation of domains
   c.   Sending it to a proxy outside the trust admin domain
		or federation of domains
   d.   Sending it to a UA

Unfortunalely caller-id and call-trace are useless without choice (d).
So my first comment is that 1d and 2d are needed in your itemized list 
of problems to solve.

I think it is a major simplification to reduce these four cases to only
two:
   a.  Sending it to a network element within a trusted admin domain
		or federation of domains
   b.  Sending it to a network element outside the trusted admin domain
		or federation of domains
(and who says PSTN gateways are always trusted? Should the GW generate
a private used-once phone number for the call attempt?)

And, as much as I'd like to believe your comment that no additional work
is required to implement 3c, are we really willing to leave it that all
services will break if anonymity is requested?  Or should services
be designed with this in mind?

Bill Marshall
[email-masked]

---

From: Rohan Mahy <[email-masked]>
Date: Fri, 19 Apr 2002 16:48:37 -0700

---- Original message ----
>Date: Fri, 19 Apr 2002 15:00:28 -0400 (EDT)
>From: William Marshall <[email-masked]>  
>Subject: Re: [Sip] Proposed plan for Network-Asserted 
ID/Privacy  
>To: [email-masked]
>Cc: [email-masked]
solution for
>   c.   Sending it to a proxy outside the trust admin domain

OK, I agree that this list is clearer than the one I proposed.

>So my first comment is that 1d and 2d are needed in your 
itemized list 

Lets assume that the Network Asserted ID is stripped as it 
leaves a trust boundary only if privacy is requested (so you 
get 1d).  Then the only problem to solve is anonymous call 
trace (2d).  I think that some providers can choose to offer 
call trace by storing accounting records for some period of 
time.  Alternatively, the provider could require a signature-
based mechanism like the one that Jon proposed.

>a private used-once phone number for the call attempt?)

To clarify, I intended for gateways which are not trusted to 
be treated like any other device in a different domain.  An 
untrusted PSTN gateway would need to be addressed using a 
signature-based mechanism.  Consequently, it would not be 
able to provide an actual phone number and just set it to 
screened.

>services will break if anonymity is requested?  Or should 
>services be designed with this in mind?

I don't think that using an anonymizer has to break features 
unless these feature explicitly need raw identity 
information.  Also, I'm not really sure what you are 
proposing instead.

thanks,
-rohan

---

From: "Peterson, Jon" <[email-masked]>
Date: Fri, 19 Apr 2002 19:21:06 -0500

I wanted to weigh in with a couple of comments on this plan, below.

Jon Peterson
NeuStar, Inc.

> Sent: Thursday, April 18, 2002 4:07 PM
> To: [email-masked]
[snip]
>  c.   Usable across administrative boundaries

I assume we understand 'across administrative boundaries' here to refer to
any 'untrusted' destination?

I really have a hard time seeing why 1b (and 2b by extension) needs to be a
separate case from 1a (and 2a). Surely PSTN gateways are 'trusted', and no
element is going to do anything differently when sending a request to a PSTN
gateway than they would do when sending it to any other 'trusted' element?

I also haven't seen any great need in my own identity draft to make use of
the distinction along the lines of 1a and 1c ('trusted' and 'untrusted') - I
feel that this distinction is motivated architectures that arise from the
absence of cryptographic mechanisms. But I understand that there are some
who want to carve the problem up this way. Personally, I view 1a, 1b and 1c
as requirements that are differentiated only by pseudoproblems.

>  c.   Usable across administrative boundaries

The distinction between 1 and 2 overall is a little fine to me as well.
Surely network-asserted identity is a way of implementing call trace, right?
Call trace implies revealing identity selectively, namely the privacy
requirements entailed in 3, but I'm not sure we need a separate category for
this. Is there something other than what we are already doing to implement 1
and 3 that we'd need to implement 2?

3 & 4 below are both fine.

> *(with gateways in the trusted domain or federation)
[snip]
> No additional work is required to implement 3c

Agreed. Nothing pressing, anyway.

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

Fine by me, obviously.

> network asserted ID (however it is expressed) to support 3d.  This would
> get used by III and IV.
> 

So, today my identity draft already contains a privacy extension for the
style of NAI provided in that draft. It declares a Privacy header priv-value
for 'auth' for this purpose. That could be generalized, certainly, though
exactly what it would entail would undoubtedly be different for different
NAI systems. In my identity draft, it entails that one SHOULD not distribute
an NAI, and if one does, it MUST be encrypted. Personally, I don't think
that relying on downstream entities to remove the NAI when they see fit is
sufficient, and this would probably be a point of contention in any attempt
to agree on a single meaning for this 'auth' priv-value.

I'd therefore like to suggest that we think a little more about this. Maybe
there's a way to generalize the syntax but not the semantics for any
particular NAI system. However, if I were the user requesting privacy, I'd
want to know whether encryption or removal were going to be used...

> 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

I don't think the mechanism you need to use for 4 should be included in this
draft - I think the manner in which you provide your identity to entities
that create NAIs has no obvious dependencies on the NAI distribution
mechanism. In so far as this may be a matter for SIP (the people that seem
to want this may have some out-of-band way of getting this data), it should
probably be in its own draft.

I'd also like to comment that I think getting the existing sip-privacy-04
mechanism into parity with a reasonable applicability, including as Flemming
sugggests robust definitions of trust, administrative boundaries, and so
forth is not necessarily a trivial task.

> I think we also need to address this topic as a charter item.
> 

Suits me. Although the mechanism my draft proposes is admittedly
heavyweight, I think it addresses the general requirements with few new
protocol mechanisms. I'm looking forward to comments on it. I have no reason
today to think that it will require a 'long term' to complete this work.

> privacy and identity between SIP and the PSTN.

Juha, among others, had argued this in the past, anyway. I think we do need
a way to map SIP's privacy apparati to the appropriate ISUP presentation
restriction bits, and so on. This is just part of the SIP-T work.

---

From: "Beck01, Wolfgang" <[email-masked]>
Date: Mon, 22 Apr 2002 15:00:27 +0200

additional NAI application inline..
> Sent: Friday, April 19, 2002 1:07 AM
> 
> [..] Below I've listed some of problems that various folks were

   d.   Usable for billing purposes; callee sends an invoice to network
        asserted caller, inbound proxies work as inline trusted third party to
        ensure non-repudiation.

> [..]

--
Wolfgang Beck
T-Systems Nova GmbH