Subject: Re: [Sipping] RE: Network Asserted Identity

From: William Marshall <[email-masked]>
Date: Fri, 19 Apr 2002 14:28:18 -0400 (EDT)

Brian Rosen wrote:
> > NAI2) The ability for a network entity to pass a 
> > (non-private) network asserted identity directly to a UA  
> I'd like to explore this one.  In my zeal to cut down the discussion to 
> manageable hunks, I don't get why we need this now.  I think NAI is 
> strictly for SP elements to assert an identity to one another, 
> and there is no requirement for any UA to see it.  If we can always 
> define NAI as inserted by the network, and stripped prior to sending to 
> a UA, then I think many things may get simpler.
> 
> It may also make other people happier with this work - UAs send 
> things they want the other UA to see.  Proxy Servers send things 
> they want other Proxy Servers to see.  I'm still assuming a B2BUA 
> is needed for really anonymous calls, and to deal with Subscriber 
> vs User issues. 

The symmetry is certainly nice.

However, we also need to account for informational items that an inbound
proxy will insert in the request for its clients.  In the same way that
an originating UA will insert informational items for its outbound proxy
(like authentication headers).  So there are really three pairwise
assiciations at work here:

   UAC <----> Proxy <----> Proxy <----> UAC
    <------------------------------------>	user<->user items
    <----------->            <----------->	user<->proxy items
                <------------>			proxy<->proxy items

The proxies in the above diagram will certainly use the user-to-proxy
items to generate the proxy-to-proxy items, and use the proxy-to-proxy
items to generate the proxy-to-user items.  Would it really "make other 
people happier with this work" if the header names were different, but 
the processing rules the same?

Leaving the philosophy, and on a more practical level, the whole
reason caller-id is a useful service is that it is NOT user-provided.

Bill Marshall
[email-masked]

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

---

From: "David R. Oran" <[email-masked]>
Date: Tue, 23 Apr 2002 15:58:37 -0400

Small quibble with Bill's assertion - not trying to de-rail the
discussion.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of William Marshall
> Sent: Friday, April 19, 2002 2:28 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: [Sipping] RE: Network Asserted Identity
>
[snip] 
> 
> Leaving the philosophy, and on a more practical level, the 
> whole reason caller-id is a useful service is that it is NOT 
> user-provided.
>
I disagree. The reason network-asserted caller-id it is/was useful on
the PSTN was because the PSTN did not have end-to-end authentication. In
all cases the callee wants to see an identity for the caller which is
vouched for by someone he trusts. In the IP world, that *could* be the
calling user's service provider, but it could just as easily be any
trusted third party.

I see no practical difference from a *caller id* perspective between an
NAI and a certificate signed by this third party saying that the From
field represents a user is who he claims to be. This can be challenged
end-to-end at the callee's discretion.

From my perspective, the *ONLY* reason the information has to originate
with the service provider rather than the user is to enable call trace,
which is something the calling user would rather NOT have happen. All
the other machinations with privacy and protecting the NAI derive from
the call trace requirement and the tricky need to do call trace while
preserving privacy.

I must be missing something basic here, given how tortuous this thread
has been and continues to be.

> Use [email-masked] for questions on current 
> sip Use [email-masked] for new developments of core SIP
>