Subject: RE: FW: [Sip] Comment, SIP Privacy draft

From: "Peterson, Jon" <[email-masked]>
Date: Fri, 29 Mar 2002 14:23:45 -0600

Some final notes (for now).

Jon Peterson
NeuStar, Inc.

> -----Original Message-----
> From: Flemming Andreasen [mailto:[email-masked]]
> Sent: Friday, March 29, 2002 11:17 AM
> To: Peterson, Jon
> Cc: 'William Marshall'; [email-masked]'; Dean Willis; Joerg Ott; Rosen,
> Brian; Rohan Mahy
> Subject: Re: FW: [Sip] Comment, SIP Privacy draft
> 
> 
> > In the past, you've made the case that
> > carrying around unverified, user-asserted identities is useful for RPID.
> > This goes very much against the spirit of the AS.
> >
> 
> No I have not. I have said (and still do), that if I receive a
Remote-Party-Id
> from an untrusted source, then I should still be able to pass that along
with
> the proper security settings (i.e. verified or not). Another source can be
> another network (for example a call originates from an Iraki service
provider
> and enters a US network) which is my motivation. Now it just so happens
that I
> can't (and won't) want to make a distiction between an untrusted user and
an
> untrusted something else, because it doesn't make any sense to me.
>

Well, in the past IIRC you've made the case that you'd like to be informed
when Mike Thomas pretends to be Elvis, but I suppose on reflection that I'd
pay money to see that too. Seriously though, do we need an RPID to carry
untrusted identity information? What's the difference between this and just
carrying the untrusted identity in the From header, then? Are you saying
then that we need multiple ways to carry untrusted information in SIP
messages (one for user-asserted untrusted info, the From, and one for
network-asserted untrusted info, the 'screen=no' RPID)? If an Iraqi network
is not considered to be part of the 'trusted' PSTN, why do we need to
preserve any identities that it has asserted (as opposed to identities that
would appear in the From)? I agree that there probably isn't much difference
between what an untrusted network and an untrusted user asserts - but I'm
not sure why that argues for retaining the concept of an untrusted RPID, I
think it actually argues for the opposite. A SIP message arriving from the
Iraqi network will have a From header that we can safely treat as an
untrusted identity - I'm not sure why we need more untrusted data.

If the From field is anonymous, and an untrusted network-asserted identity
is present in the RPID header, who would be the consumer of that untrusted
RPID? The network couldn't rely on it for accounting or malicious call trace
- it's untrusted. It shouldn't be displayed to end users - the originating
user requested anonymity. So what's the use case for it, exactly? If there
is none, then why carry it? There's got to be something here that I'm
missing.

[snip]
> -- Flemming

_______________________________________________
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, 29 Mar 2002 15:34:24 -0500

"Peterson, Jon" wrote:

> If an Iraqi network

Let the user decide - don't make your policy an integral part of the protocol.

> is none, then why carry it? There's got to be something here that I'm

Indeed there is. Just because your network cannot verify the authenticity of the
information does not mean the information is useless. With the present
semantics, some people (I'm one of them) still find it useful from a pure
caller-id service perspective to have a clear-text caller-id being presented
although it was untrusted as opposed to having nothing at all, as long as I know
it's untrusted. The longer term problem with your statement is that it assumes
that the "screen" mechanism is the only authenticity mechanism forever. As I
have stated many times, we expect a generic security solution that can
authenticate various headers in the future. Once we get that, you can now have a
Remote-Party-Id signed, sealed and delivered from an "untrusted" network and
actually still be able to verify it even though your network provider can't
vouch for it. Pretty useful - no ?

-- Flemming