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

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

---- Original message ----
>Date: Fri, 19 Apr 2002 09:52:42 -0400
>From: Flemming Andreasen <[email-masked]>  
>Subject: Re: [Sip] Proposed plan for Network-Asserted 
ID/Privacy  
>To: Rohan Mahy <[email-masked]>
>Cc: [email-masked]
>
>
>
>Rohan Mahy wrote:
>
>> 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.
>
>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 ?

Fair enough.  Let's say for now that a trusted entity is 
trusted not to maliciously modify messages, or 
reveal "private" network asserted ID information outside 
the "trusted" federation.  So, ordinary UAs in "my" service 
provider network are not trusted.

>> This would solve
>> 1a, 1b, 2a, and 2b.
>
>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).

OK, I hope we agree that 1a, 1b, and 2b would by solved by 
the scaled down mechanism.  You could still provide call 
trace (2a) within this network by using accounting 
mechanisms.  You will probably say that insuring you have an 
accounting record for each call is a burden.  Also, you do 
lose the ability to do call return with this mechanism, but I 
do not consider this a short-term requirement.  (You might 
disagree).

><snip>
>
>>
>> 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.
>
>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 think we need to decouple them now, and can join them again 
if it makes sense.

>> 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
>>
>
>It's unclear that 3b is independent of which mechanism you 
choose to provide
>the hint above.

I don't follow you.

>> 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.
>
>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.

I think it does provide a solution here for a small scope.

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: Mon, 22 Apr 2002 18:27:25 -0400

Rohan Mahy wrote:

> the scaled down mechanism.

Sure.

> You could still provide call

> do not consider this a short-term requirement.  (You might

Indeed I do disagree. From the very first version of this
"forbidden-name" draft, the motivation section stated the need for
providing CLIP/CLIR services while supporting call trace. SIP itself has
adopted the idea of pushing state to the endpoints for later retrieval
and we even have a more general work item building on this in the form
of state/cookies. Being able to send down an opague URI that can be used
as the target for a subsequent call trace still seems like a pretty good
idea to me. What is the problem with this and what alternative do you
suggest for the UA to invoke the trace ?

> i think we need to decouple them now, and can join them again

All right - I suppose we can always define a duplicate header to make
the purists feel good.

> >It's unclear that 3b is independent of which mechanism you

If you were to use Remote-Party-Id for the user-provided info, and
Remote-Party-Id for network-asserted identity has a way of indicating
privacy, then it would be rather silly to now require a completely
different mechanism to provide privacy for this user-provided
Remote-Party-Id.

> >> network asserted ID (however it is expressed) to support

Again, I don't think it is desirable to require a multitude of
extensions to solve a single problem. The "forbidden-name" draft as
defined today already solves this for network-asserted identity and I
don't see why I can't continue doing that.

> I think it does provide a solution here for a small scope.

Too small IMHO. It's basically useless without additional extensions.
Paraphrasing Jon here, it would seem that too much has now been taken
away.

-- Flemming