Subject: [Ecrit] faux privacy concerns

From: Andrew Newton <[email-masked]>
Date: Fri, 1 Sep 2006 16:25:25 -0400

One of the reasons given for needing to do the try-with-TLS-then- 
retry-without scheme is that of privacy concerns.  However, as James  
Winterbottom stated, LoST does not transmit any identity  
information.  If an attacker can eaves drop on a LoST session, all  
they get is location information.  They do not get any user identity  
to associate to that location information.

Given that the try-with-TLS-then-retry-without scheme has serious  
consequences regarding the scalability of the LoST system and offers  
a security model that is easily foiled for a benefit that is of  
limited value, this scheme should not be considered.

-andy

_______________________________________________
Ecrit mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ecrit

---

From: "Marc Linsner" <[email-masked]>
Date: Fri, 1 Sep 2006 16:31:14 -0400

> 
> One of the reasons given for needing to do the 
> try-with-TLS-then- retry-without scheme is that of privacy 
> concerns.  However, as James Winterbottom stated, LoST does 
> not transmit any identity information.  If an attacker can 
> eaves drop on a LoST session, all they get is location 
> information.  They do not get any user identity to associate 
> to that location information.

But, it does reveal that an emergency of some kind *could be* happening at a
the exposed location.

-Marc-

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 01 Sep 2006 16:38:08 -0400

Plus, if you can intercept other streams, you might be able to guess 
pretty well. For example, if somebody uses SMTP, POP or IMAP, you can 
relate the IP addresses and get a location/userid mapping. Once you have 
an email address, Google gives you the name. See the recent AOL search 
query debacle for related work...

That said, I think it is a lower-order privacy breach, particularly as 
many of these identify-revealing protocols are now being encrypted 
themselves.

---

From: Andrew Newton <[email-masked]>
Date: Fri, 1 Sep 2006 16:40:58 -0400

> But, it does reveal that an emergency of some kind *could be*  

Given that an attacker could also listen in on the RTP stream and  
hear the caller give the location to the PSAP when asked to verify,  
this is not that big of a concern... especially for the trade-off of  
much more overhead for crappy security.

-andy

---

From: "Marc Linsner" <[email-masked]>
Date: Fri, 1 Sep 2006 17:13:16 -0400

> > But, it does reveal that an emergency of some kind *could be* 
> > happening at a the exposed location.
> 
> Given that an attacker could also listen in on the RTP stream 
> and hear the caller give the location to the PSAP when asked 
> to verify, this is not that big of a concern... especially 
> for the trade-off of much more overhead for crappy security.
> 
> -andy

Now you're listening, before you were messing with packets...different
paradigm, I think.  Listening to TLS LoST query gains you nothing.  Not the
expert, but listening appears easier than messing with packets.

Again, not the expert, but I heard the marketing.  TLS LoST queries:

1) The querier knows if the data has been messed with.
2) A chance that an after-the-fact audit will reveal whether the responding
LoST server is a real one.

True?
Does the benefit outweigh the effort?

-Marc-

---

From: Andrew Newton <[email-masked]>
Date: Fri, 1 Sep 2006 17:31:52 -0400

> expert, but listening appears easier than messing with packets.

Yes, but it doesn't take much more.  After all, script kiddies have  
the tools at hand to synthesize packets.

> LoST server is a real one.

Actually, the querier probably just knows that TLS didn't work and  
that they dropped back.  Unless they are doing active intrusion  
detection, they probably don't know somebody messed with their  
stuff.  A scheme that is an order of magnitude more chatty and latent  
without useful security is likely to be of little comfort to those  
doing a postmortem (in some cases, literally).

> Does the benefit outweigh the effort?

Absolutely not.

-andy

---

From: "Marc Linsner" <[email-masked]>
Date: Fri, 1 Sep 2006 17:40:17 -0400

> > paradigm, I think.  Listening to TLS LoST query gains you 
> nothing.   
> > Not the
> Yes, but it doesn't take much more.  After all, script 
> kiddies have the tools at hand to synthesize packets.
> 
> > 2) A chance that an after-the-fact audit will reveal whether the 
> > responding LoST server is a real one.
> 
> Actually, the querier probably just knows that TLS didn't 
> work and that they dropped back.  Unless they are doing 
> active intrusion detection, they probably don't know somebody 
> messed with their stuff.  A scheme that is an order of 
> magnitude more chatty and latent without useful security is 
> likely to be of little comfort to those doing a postmortem 
> (in some cases, literally).

You certainly add a level of comfort to on-line banking applications!

:^)

-Marc-

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 5 Sep 2006 10:27:03 -0400

There are many attacks that are going to work.  Denial of service is one of
them, and whether you use TLS or not.  A downgrade attack will also work.
I don't see that problem even within an order of magnitude of the problem of
wholesale forgery of location.  I really see forgery as an actual problem,
affecting a lot of people, compared to a downgrade attack, affecting a
specific person placing an emergency call.  Think about what you need to
organize forgery, and compare that with what you need to do a downgrade
attack.  The former is easy, the latter is quite hard, albeit possible.

I DO think analyzing attacks that assume an attacker can listen to any
packet and generate any packet is the correct way to look at the security of
the system.  If I could think of a practical way to prevent this kind of
attack, I'd support it.

I think the effort involved in trying TLS and falling back is small.  I
think the benefit is fairly large, but not overwhelming.  I think the
tradeoff favors doing it.

Brian

> -----Original Message-----
> From: Marc Linsner [mailto:[email-masked]]
> Sent: Friday, September 01, 2006 5:40 PM
> To: 'Andrew Newton'
> Cc: [email-masked]'
> Subject: RE: [Ecrit] faux privacy concerns
> 
>

---

From: Andrew Newton <[email-masked]>
Date: Tue, 05 Sep 2006 10:37:32 -0400

> attack.  The former is easy, the latter is quite hard, albeit possible.

Forgery of what?

> tradeoff favors doing it.

I completely disagree.  You are hobbling the system with much more traffic 
than it needs to handle, for a security benefit that is easily thwarted and 
a privacy benefit that is of secondary need.

-andy

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 5 Sep 2006 10:56:32 -0400

Forgery of location: a script kiddie creates a call with a totally forged
identity and location.  Responder resources are sent on a wild goose chase.

The current 9-1-1 system does not allow this.  Location cannot be forged.
Neither can identity. 

There is no evidence that this will hobble the system.  The traffic is such
that reasonable servers can easily handle the expected load WITH TLS.  The
security benefit is not easily thwarted.  That it cannot thwart other
attacks (like downgrade attacks) does not diminish the fact that forgery is
a real, likely-to-happen concern, and the other attacks, while definitely
feasible, are much less likely to happen, and cause much less damage when
they do.

Brian

> From: Andrew Newton [mailto:[email-masked]]
> Sent: Tuesday, September 05, 2006 10:38 AM
> To: Brian Rosen
> Cc: 'Marc Linsner'; [email-masked]'
> Subject: Re: [Ecrit] faux privacy concerns
> 
> Brian Rosen wrote:

---

From: Andrew Newton <[email-masked]>
Date: Tue, 05 Sep 2006 11:09:36 -0400

> feasible, are much less likely to happen, and cause much less damage when

You are right that forgery is not easily thwarted by server side certs and 
TLS, because that scheme never protected against forgery in the first place.

I'd also like to point out that even if you do institute some sort of 
forgery protection against a LoST server, you still haven't solved the 
problem.  Forgery of location information against a PSAP is a conveyance 
issue.  An attacker can be honest with a LoST server all day long and still 
lie to a PSAP.

-andy

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 05 Sep 2006 11:13:58 -0400

> The current 9-1-1 system does not allow this.  Location cannot be forged.

This isn't really true. While it is not possible for somebody in Nigeria 
to pretend to be in Toledo, most cellular callers in rural areas can 
pretend to be in areas spanning dozens of square miles of territory, 
which yields just about the same wild goose chase. With no-SIM phones or 
stolen phones, the calls are also anonymous.

I'm not arguing that this is desirable, just that we shouldn't pretend 
that this is a new threat.

> feasible, are much less likely to happen, and cause much less damage when

As discussed before, I believe that identity assertion is a much more 
practical and likely-to-be-successful approach to severely curtailing 
malicious or prank calls, together with some standard network-level 
sanity checks that tags calls from Outer Mongolia.

Unlike in the cellular world, where a monthly subscription fee makes it 
necessary to allow for no-SIM calls, the need is far less in VoIP. I can 
have a fallback emergency "carrier" with authentication and 
authorization that requires no subscription fees.

Thus, maybe we should start with defining requirements, not assuming 
solutions. There may well be other solutions that are more readily 
deployable and avoid the issues being discussed here. For example, it 
may be sufficient to have an "access provider cert" that simply attests 
that I'm currently using a particular ISP or maybe a particular POP or 
DSLAM.

Henning

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 5 Sep 2006 11:22:42 -0400

> issue.  An attacker can be honest with a LoST server all day long and
Absolutely.  I'm trying to get everything to work the same way, for the same
benefit.

I am guilty of mixing parts here, forgery is MORE of a concern with
conveyance.  The biggest benefit to TLS in LoST is privacy.  If the endpoint
sends its location, you know it belongs to the endpoint.  There is a smaller
concern about integrity protection.  You don't have a client authorization
problem on the general query, but you do have a server side issue: the
client would like to know that it is talking to the entity it thinks it is.
I'd like to do better than that (have a real CA for the LoST servers), but
that is probably not realistic most places.

In LoST, I think we can leave it up to the client.  The server MUST support
TLS.  The client can choose to use it or not.  Wording around that would be
in -phonebcp.

Would you not agree that MUST IMPLEMENT TLS is a reasonable requirement?
Would you not agree that even with server certs, you do get privacy, albeit
downgrade attacks are possible?  Is that not still a fairly significant
gain?  From the client point of view, wouldn't it seem like trying TLS to
get the privacy is a worthy use of the cycles?

Brian

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 5 Sep 2006 11:32:05 -0400

> that this is a new threat.
No, actually, a Phase II carrier network has a 50 meter accuracy everywhere,
and it's not forgeable.

The silliness that an uninitialized mobile can't deliver location is true,
but should never have been allowed.  It's a big hole.

...snip...
> sanity checks that tags calls from Outer Mongolia.
Well, identity does help, no question about it.  Is it sufficient?  I don't
think so, primarily because I think we have to assume no carrier is
possible.  If there is no carrier, identity assertion becomes problematic.
If we outlaw Marc's home proxy delivering calls to the PSAP, then we might
be able to state that identity is sufficient.  Hmmm, maybe not, because
Sierra Leone VoIP Service Pty could make an assertion, but who would trust
it?  Also note, of course, that identity helps you after the fact.  Possibly
the identity has more to do with the access network?

> authorization that requires no subscription fees.
Sure, although I doubt this will happen.  For what it's worth, the lack of
identity and location is sufficient to cause the 9-1-1 guys to actually want
to outlaw the whole thing.  They'd probably rather it worked well, but would
prefer not work at all to work poorly.  No one believes that the regulation
to require it of mobile carriers will be changed however.  

> that I'm currently using a particular ISP or maybe a particular POP or
Yeah, maybe.  Need a system level discussion though, I think, not just LoST
centric.

Brian

---

From: Andrew Newton <[email-masked]>
Date: Tue, 05 Sep 2006 11:42:54 -0400

> Would you not agree that MUST IMPLEMENT TLS is a reasonable requirement?

That is a very reasonable requirement.

> downgrade attacks are possible?

You get privacy from somebody casually sniffing traffic.  Anybody who wants 
it will get it.

>  Is that not still a fairly significant

I guess it would be fairly harsh of me to judge somebody for placing far 
more emphasis on their location privacy than having their house fire 
extinguished.  I'm just silly that way.  So if somebody wants to configure 
their phone that way, we should let them.

However, that is a far cry from suggesting that everybody SHOULD do it.

And from a network point of view, it does have implications.  In simple 
terms, it means the network will be overloaded that much faster.

-andy

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 5 Sep 2006 11:48:02 -0400

Okay, so maybe we've converged everywhere except what it says in -phonebcp
about client behavior.

I'll leave that until another day.  For now, we know what the LoST document
should say about it, if everyone else agrees:

TLS is MUST Implement
Server certs are required

Would you accept: client certs are optional?  

Brian

> Sent: Tuesday, September 05, 2006 11:43 AM
> To: Brian Rosen
> Cc: [email-masked]'

---

From: Andrew Newton <[email-masked]>
Date: Tue, 05 Sep 2006 11:54:37 -0400

> TLS is MUST Implement

Agreed.

> Server certs are required

I disagree.  If a LoST administrator doesn't want to do it, then forcing it 
upon them is only gonna get an unpredictable result.  Additionally,  client 
implementers should be told that they need to be intimately aware of how 
their TLS work in case they do not recognize the server cert: in other 
words, they need to be very sure that their TLS library allows them to 
ignore unknown certs and continue the TLS conversation.  Otherwise, they 
should simply not use it.

> Would you accept: client certs are optional?  

Agreed with the similar warning as above, except geared toward server 
implementers.

-andy

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 5 Sep 2006 12:02:36 -0400

> should simply not use it.
I'm sorry, I don't understand.  Are you actually saying that
TLS-with-server-certs should not be mandated, or are you saying that there
needs to be text around a mandate that explains the issues?

If TLS is MUST IMPLEMENT, then what else, besides server certs, is an
acceptable MUST IMPLEMENT ciphersuite?  I presume we otherwise would be
saying RSA-1024, SHA-1/2, AES.

Brian

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 05 Sep 2006 12:03:03 -0400

> extinguished.  I'm just silly that way.  So if somebody wants to 
> configure their phone that way, we should let them.

I think we need to be a bit more careful in this discussion in terms of 
timing. I'm hoping that in almost all cases, there will be no LoST query 
at the time of the call, since that query had already been done hours or 
days before, when the mobile moved into a new coverage area.

Thus, a reasonable algorithm might be:

(1) use TLS (server cert only) for LoST iff not in an emergency; if that 
fails for some reason, alert user and system operator (VSP); the bcp 
should suggest appropriate ways to determine ways to alert the operator

(2) use plain-text LoST if the query is made at the time of the 
emergency call, given the trade-offs involved

This approach also greatly reduces the impact of large-scale emergencies 
on the LoST infrastructure.

Henning

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 05 Sep 2006 12:10:26 -0400

> No, actually, a Phase II carrier network has a 50 meter accuracy everywhere,

Right. And the deployment of Phase II is universal :-)

> the identity has more to do with the access network?

We went through this already; with location or identity, you'll have the 
problem of entities making assertions that you haven't met before, be 
that Sierra Leone VoIP Service Pty or Brooklyn Bakery and Undertaker, 
LLC, for either location or identity.

> to require it of mobile carriers will be changed however.  

I believe it when I see - it won't be a pretty sight after the AARP 
lobbyist has had it with the NENA lobbyist :-)

> Yeah, maybe.  Need a system level discussion though, I think, not just LoST

Location assertion has nothing to do with LoST and seems completely 
useless for LoST.

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 5 Sep 2006 12:10:34 -0400

Henning

If this infrastructure was not needed in disaster situations, then I would
agree with you.

My problem is that experience suggests that everything you think will work
in a disaster often doesn't, and stuff you weren't so sure about often does.

I don't want an assumption made that the mapping you got yesterday is still
valid.  If it's all you got, and you can't get more, by all means use it,
but TRY to get current data.

That would mean rerunning the query at the time of a call.

If there was a way to reliably signal a disaster, so we only did that when
disaster struck, great, but that ain't gonna happen.  To me, that means try
with TLS and fall back, on every call.

I think the timeouts on the try should be very short; if you get the TLS
response real fast, use it, otherwise retry without it.  

Brian

> From: Henning Schulzrinne [mailto:[email-masked]]
> Sent: Tuesday, September 05, 2006 12:03 PM
> To: Andrew Newton
> Cc: Brian Rosen; [email-masked]'

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 05 Sep 2006 12:14:36 -0400

We just have to disagree on this point. I believe LoST is the completely 
wrong system level to do short-time scale changes to PSAPs. This has 
nothing to do with TLS. We have many more suitable ways to do 
redirection that are actually designed for this purpose.

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 5 Sep 2006 12:30:21 -0400

We may indeed have to disagree, but let me try one more time.

The assumption you are making when you assert that there are more suitable
ways to do redirection is that all of the calls originally intended for one
destination (could be a PSAP) should go somewhere else; the redirection is
always at the right hand side of the URL.

That may not be the case, and you may not be able to make that work.  I
think we need the ability to actually change the routing (think changing the
polygon that defines the area that gets a particular route if it was all map
based).  

I'm not thinking this is done on a routine basis; we do that will TTLs and
DNS.  I'm thinking when the world falls apart, flexibility is the key to
survival. 

I'll admit that for every scenario I can come up with, there is a better way
to accomplish the task IF YOU THINK ABOUT IT BEFOREHAND.  The problem is
that we know we don't do a good job at predicting scenarios.

Brian

> Sent: Tuesday, September 05, 2006 12:15 PM
> To: Brian Rosen
> Cc: 'Andrew Newton'; [email-masked]'

---

From: Andrew Newton <[email-masked]>
Date: Tue, 05 Sep 2006 12:30:37 -0400

> emergency call, given the trade-offs involved

This is very reasonable, and sounds good to me.

-andy

---

From: Andrew Newton <[email-masked]>
Date: Tue, 05 Sep 2006 12:33:31 -0400

Henning Schulzrinne wrote:
> We just have to disagree on this point.

I agree.  :)

-andy

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 05 Sep 2006 13:01:05 -0400

The problem is that such solutions come with significant costs. In 
particular, they make any kind of local resolver caching fail - and 
since nobody knows ahead of time when the feature might be used, it 
becomes unusable to begin with.

At the very least, I would like to make this "feature" (I'm sorry, I see 
this as a mis-feature) be made optional, so that an operator of a 
particular region can decide that the significant cost and operational 
implications are not worth the price.

---

From: Ted Hardie <[email-masked]>
Date: Tue, 5 Sep 2006 10:13:12 -0700

At 12:30 PM -0400 9/5/06, Andrew Newton wrote:
>>(1) use TLS (server cert only) for LoST iff not in an emergency; if that fails for some reason, alert user and system operator (VSP); the bcp should suggest appropriate ways to determine ways to alert the operator
>>
>>(2) use plain-text LoST if the query is made at the time of the emergency call, given the trade-offs involved
>

In point one, is the intent to alert the operator of the LoST server or the other
parties (e.g. if the LoST server is derived from the access provider, are you
notifying them or the VSP?)

In point two, I agree that this is a good idea, and I think it reinforces the
point made earlier by Brian.  The terminal needs to know that a specific
call is an emergency call.  That will enable you to invoke this downgrade,
as well as re-checking the mapping (at least Brian and I want to do this,
and it should be possible, even if not mandated).

			regards,
				Ted

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 05 Sep 2006 13:20:37 -0400

> notifying them or the VSP?)

The operator of the LoST server contacted. Presumably, if the local 
resolver recurses, it would discover the error and alert its owner.

I don't think returning such an address (only) via LoST is a good idea 
as it then leads to attacks where the bad guy interferes with TLS, 
redirects you to his rogue server, which contains the email address 
[email-masked]

One possibility is a DNS entry, but there are probably better ideas.

Including this *also* in the LoST response is probably helpful.

Henning