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

From: "Peterson, Jon" <[email-masked]>
Date: Mon, 1 Apr 2002 06:58:52 -0600

A few more comments below.

Jon Peterson
NeuStar, Inc.

> -----Original Message-----
> From: William Marshall [mailto:[email-masked]]
> Sent: Friday, March 29, 2002 9:23 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: RE: [Sip] Comment, SIP Privacy draft
> 
> 
> > Specifically, I am concerned with RPID usage as a replacement for the To
and
> > From headers, in architectures which have proposed that To and From
should
> > always contain random/anonymous information for all calls (not just when
> > privacy is needed) and RPID alone should be used to assert originating
and
> > destination identities. 
> 
> privacy-04 already says that UA's don't insert RPID headers.  If a UA
> is going to do it anyway, I don't see how a MUST NOT will stop it.
> At the proxy, it still needs to handle INVITEs from both trusted
> and untrusted sources, so considering the UA an untrusted source
> simplifies the number of cases to specify and handles some errors.
> I'd tend to agree that such architectures may cause interoperability
> problems, but have no basis in facts for that belief.
> 

Until sip-privacy removes the 'screen=' parameter, sip-privacy still has
sunny-day handling for the insertion of RPID headers by untrusted UAs. I'm
not suggesting that we add text saying that untrusted UAs MUST NOT add the
RPID. I'm suggesting that the concept of an 'untrusted' RPID be expunged (by
removing the 'screen' concept and the associated protocol apparatus), and
that proxies MUST remove RPIDs they receive from untrusted sources. I think
would be much more effective.

> >					If you would like to see
> > the changes I suggested, they are available in the ML archives here
> > 
> http://www1.ietf.org/mail-archive/working-groups/sip/current/msg04258.html
> 
> Flemming already responded to this message, point by point, 
> msg04277.html.
> 

Yes, Flemming did reply to my comments, but I don't think that exchange
necessarily resolved the open issues. Since that time (especially during the
WG meeting in Minneapolis) I've been focusing primarily my efforts on just
the first issue in my mail, the 'screen=' parameter. If we get past this
I'll move on to further issues -  I feel 'screen' has the highest priority.
Suffice it to say that I'm not backing away from any of my other arguments -
I'm just trying to handle one matter at a time.

> > There are also some issues with the mechanism in so far as a trusted
entity
> > sends out a chunk of encrypted data in an RPID that only it can decrypt,
and
> > then expects entities that want access to this information to 'get back'
to
> > them via the given hostname and port. First of all, while it may be
> > specified elsewhere, nothing that I can see in sip-privacy-04 tells me
how I
> > can 'get back' to the host that generated the encrypted data. 
> 
> Section 7.2 clearly states that it generates a sip: or sips: URI,
> and has requirements for the content of the hostport, and for the
> contents of the username, and for a user-param.  Section 6.1 states
> that such a URI can be used as a Request-URI by the UA for certain
> call control functions or subsequent calls.  While the mechanisms you
> described can also be done, a simple INVITE to the enrypted URI
> is simpler.

So, then, you mean that I'm supposed to send an INVITE to the hostname and
port identified in the encrypted URI when I want that URI translated? I had
gotten the impression from the text that I could use the hostname and port
to query for a translation of the encrypted URI to its original form. I
guess I got that impression from the line in 6.1:

   ... whereas the "hostport" 
   identifies the entity that can decrypt the information

But now I can see how this admits of either reading. However, I'm a little
confused about how this is then supplying a valuable privacy service. When I
request privacy for a call, I don't exactly expect that the person I'm
calling will be able to call me back. But 7.2 suggests that encrypting the
URI in this way makes it suitable for transmission to untrusted entities. Is
this the desired behavior? Or does the server decrypting the URI make some
further decision to disallow certain requests to that URI? If so, this
should at least be mentioned.

As a means of malicious call trace (which I assume is the motivating
requirement) this also seem a little counterintuitive, especially if, as the
tracing network, I don't intend to start a session with the entity
identified by the URI. Is there some other request (maybe part of the
'certain call control functions') you mention above that I can send that
will just result in the decrypting of the URI? Or should the tracing network
requests a translation out-of-band somehow?

I must also point out that the other concerns I raised in my previous mail
are quite material to whether or not this is encryption mechanism is
genuinely implementable. There really are a lot of points that would need to
be resolved.

> > 		....  whereas the Call-Info means "this is
> > unimportant information that the end user should display if they can,
> > otherwise, don't worry about it."
> 
> My old rotary phone does exactly this with the Caller-ID 
> info.  Perhaps I need to upgrade my UA.

When I read things like this I'm really not sure if you're being serious.
Are you honestly suggesting that it doesn't matter whether or not the
network-verified identity for a request is presented to the UAS and end
user? That it doesn't matter if trusted network elements communicate such
identities to untrusted elements? I'd like to think it is clear from my
wording above that Call-Info is 'optional' in the sense that users can
display it if they like, whereas RPID has strict rules concerning whether or
not a UA is eligible to receive the network-verified identity - this is
unrelated to whether or not the UA can display it. Hence the distinction I
attempted to draw between selectively rendering the content (RPID) and
rendering optional content (Call-Info). There are restrictions on where RPID
is passed that do not currently exist for Call-Info.

> Bill Marshall
> [email-masked]

_______________________________________________
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, 01 Apr 2002 09:46:58 -0500

> would be much more effective.

You are concerned about somebody doing something the draft does not define, and
in fact explicitly states it is not intended for. You have not provided any
technical problems with this, but are only concerned with the potential for
misuse. There is no point in either of us continuing to repeat the same
arguments on this point. If somebody else feels strongly about this point and
has something technical to offer, they should speak up.

> calling will be able to call me back.

Bill already explained how malicious call trace works - you will not be able to
call that party back.

-- Flemming

--
Flemming Andreasen
Cisco Systems

---

From: "Ben Campbell" <[email-masked]>
Date: Mon, 1 Apr 2002 11:11:48 -0600

> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Flemming Andreasen
>
> "Peterson, Jon" wrote:
>
> >

The issue Jon talks about is more philisophical than technical, so it is
hard to offer something technical. The problem is, what sort of errors can
occur? If an untrusted RPID is present in a message, then a UA should not
trust it. It is rather unclear to me what useful thing a UA can do with an
RPID _without_ trusting it, other than perhaps displaying it to the user
with some sort of "don't trust this" disclaimer.

Now, that behavior would be similar to today's use of email, where your
email reader reports this message is from me simply due to an untrusted from
header. Unfortunately, less sophisticated users do not understand what it
means when I say that From: is untrusted. They will assume the email is from
me, unless there is some evidence to the contrary. Indeed, they will tend to
doubt me if I were to say that I did _not_ send the email. I bring up email
only as an existance proof that the general public will often screw up when
handed an untrusted identity--and to suggest that we do not repeat that
design mistake.

So, an untrusted RPID allows a mistake on the part of the UA (perhaps doing
some sort of automatic processing) or by the user (by not really
understanding what trust means.) This creates a fail-unsafe condition (that
is, a failure on the part of the UA does damage)

If there were no RPID at all, both of these mistakes are impossible. This
creates a fail-safe situation, where the UA (and user) are unable to hurt
themselves by improperly handling the information.

Now, the only real _advantage_ I can think of keeping untrusted RPID headers
is the situation where one hop cannot verify the identity, but the next hop
can. But if I read the screen token section correctly, a "no" always wins if
there are multiple screen tokens. So, if P(1) says no, and P(2) says yes,
the UA should still treat the value as "no." Is this the intended
interpretation?

---

From: Flemming Andreasen <[email-masked]>
Date: Mon, 01 Apr 2002 12:37:25 -0500

> with some sort of "don't trust this" disclaimer.

That's the hard part about discussing philosophy which is why we really
shouldn't, because we are not all going to agree. I do believe the above is
actually useful, inasmuch as it is better than not getting anything at all.

> handed an untrusted identity--and to suggest that we do not repeat that

I would argue the other way and actually see e-mail as an excellent existence
proofs that this is both workable and useful. People that are not content with
that level of security can for example PGP sign their e-mails and get better
security. Similarly, if people are not happy with the screen parameter, they can
define a more comprehensive and general security solution and start applying
that on top. What is the problem here ?

> is, a failure on the part of the UA does damage)

There is no end to what kind of mistakes can be made by a UA. Using this kind of
logic, we should then note that bad things can happen if you blindly trust the
information provided in the From header field, and hence we should make sure
this can't happen by obfuscating the From header field. However, nobody is
seriously arguing this way for good reason.

> themselves by improperly handling the information.

If you really want to apply that philosophy to the SIP protocol, then we have a
lot of unfinished work ahead of us. It certainly hasn't been a design principle
so far.

> can.

That is one advantage. Also, the ability to have a stronger security solution
applied on top is another (and I still think there is value in an untrusted
Remote-Party-Id as opposed to no Remote-Party-Id at all).

> But if I read the screen token section correctly, a "no" always wins if

Strictly speaking yes, but that part doesn't really apply here (there's only
supposed to be one token). If P(2) can actually authenticate the
Remote-Party-Id, it should set the screen parameter to "yes" (if there is a "no"
parameter, it should be removed).

-- Flemming

--
Flemming Andreasen
Cisco Systems

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 01 Apr 2002 12:54:58 -0500

> handed an untrusted identity--and to suggest that we do not repeat that

In the absence of a PKI or only receiving email from parties that you
have a shared key with, would you suggest we remove or don't display the
From header in email? The problem is that it works for 99+% of the cases
without authentication, so removing this capability without a credible
replacement isn't too helpful, even if it makes the purists feel better.

> the UA should still treat the value as "no." Is this the intended

Or if you treat this as yet another indication of what the sender may
be. If I recognize the name, there's a high likelihood that it is
correct, just like From headers in email, but before I send $100,000 to
the account listed at a bank in Nigeria, trust that this is indeed BMW's
Director of North American operations (to cite another semi-public
version of identity fraud) or open that binary attachment, I'd rather
confirm that this is safe. As the latter case shows, the major damage
that identity impersonation does today would not be cured by a trusted
identity at all.

Unless it can be shown that the From header in SIP-bis subsumes all of
the RPID functionality, I fail to see what the harm is of providing
additional information, as long as it is labeled appropriately.

I can see one minor advantage: It does add the equivalent of the
X-Authentication header in email, namely an indication that From and
identity as seen by a proxy doesn't match, which would presumably be a
clue that something might (or might not) be amiss. Yes, it can be faked,
but it makes life a tad harder for SIP spammers using relays.

---

From: "Ben Campbell" <[email-masked]>
Date: Mon, 1 Apr 2002 16:07:38 -0600

> From: Henning Schulzrinne [mailto:[email-masked]]
> Sent: Monday, April 01, 2002 11:55 AM
> To: Ben Campbell
> Cc: Flemming Andreasen; Peterson, Jon; 'William Marshall'; [email-masked]
> Subject: Re: [Sip] Comment, SIP Privacy draft
>
>

The problem is that untrusted From headers in email has led to a general
population of users that believe they _can_ trust the from header.

> that identity impersonation does today would not be cured by a trusted

I assume you are referring to the explosion of email worms? I think that is
another problem entirely and only tangentally related to the discussion.

---

From: "Ben Campbell" <[email-masked]>
Date: Mon, 1 Apr 2002 16:28:47 -0600

> From: Flemming Andreasen [mailto:[email-masked]]
> Sent: Monday, April 01, 2002 11:37 AM
> To: Ben Campbell
> Cc: Peterson, Jon; 'William Marshall'; [email-masked]

The problem here is that email clients _don't_ make it clear that you cannot
trust the from information. You seem to think the general populace of email
users understand that they cannot trust the identity for unsigned messages,
or even understand what it means to trust or not trust an identity. Maybe
people just don't care--PGP must not have been a big seller to die off as a
commercial product. Or more likely they just don't understand. The point is,
if you provide untrusted information here, people will trust it anyway.

> lot of unfinished work ahead of us. It certainly hasn't been a

"We should stop repeating a mistake" and "We should go back and fix every
occurance of a mistake" are not equivalant assertions.

> Remote-Party-Id as opposed to no Remote-Party-Id at all).

Are you thinking that someday the RPID might have some sort of signature
that could be verified by the UA, but not by a proxy? Well, when we have
such I would be perfectly happy to have the proxy send on an RPID it cannot
verify, as long as the proxy can see that it contains something that might
be verifiable by the client. (In general, that is the same as the multihop
scenario below, I think.)

> parameter, it should be removed).

On a re-read of the proxy behavior section, I can see how that is the case.
I suggest if this behavior stays in spec, that the proxy behavior wording be
tightened a little bit. Someone not privy to these conversations might not
interpret the statement that there must be no more than one screen token to
mean the same as "the proxy must remove all previous screen tokens."

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 01 Apr 2002 20:33:29 -0500

> population of users that believe they _can_ trust the from header.

This seems to be a user interface problem as much as a protocol problem.
Even regular users seem to have learned to distinguish the open/closed
lock icon on web browsers indicating trust levels. Since there doesn't
seem to be a viable alternative in the foreseeable future, given ample
opportunity in the email space to develop one, I don't see how this
discussion is particularly helpful.

> another problem entirely and only tangentally related to the discussion.

I was trying to highlight three different aspects of
(mis)identification:

1) In some cases, even a certified identity doesn't help any. The
various Outlook attachments are an example where being 100% sure that
you sent the email is probably harmful as it may lead me to trust the
attachment more than I should.

2) See http://slate.msn.com/?id=2063114 for a recent "interesting" case
of email spoofing. In that case, the name of the author probably was
less important than his (faked) corporate affiliation. In that case, a
user agent that detected a set of incongruous routing headers and
flashed a warning probably would have been more helpful.

3) For most people, impersonation is not a major problem, as far as I
can tell. I don't get spam from known people (yet) and I doubt that most
of the email scams rely on impersonation. Having a certified identity
for [email-masked] isn't particularly helpful.

Unlike email, with SIP it should be relatively easy to check whether an
address is valid in real time. (Indeed, having an identity that can be
verified if reachable, but is not callable, could be a useful service.)
True impersonation is also fairly hard to scale to the levels needed to
make spam work, as the spammer has to have access to my address book or
impersonate some well-known person. Most people would be suspicious if
they got email from Britney Spears.

Given the lack of real incentives for most people, I doubt that
certified identity is high on people's list of things to spend money on.
Certificates would have to be easily trusted (small number of global
CAs) and easily movable (as otherwise most calls from hotel and
payphones would remain unauthenticated).

Thus, I find it somewhat unfair and not particularly helpful to make
principled objections on "holier-than-email" grounds, particularly
absent a credible proposal that addresses these issues and has any real
chance of being deployable in years measured in single digits.

I would hope that RPID is going to be the exception, as S/MIME-signed
messages might offer a reasonable alternative, but not something we can
mandate as the only solution.