Subject: [Sip] RFC 4474 and PSTN

From: "Elwell, John" <[email-masked]>
Date: Fri, 04 Apr 2008 09:19:06 +0100

There seems to be some interest in adding some indicator to the URI or
to the header field to warn of the limited guarantee of authenticity or
the opposite (i.e.,lack of such an indicator would mean the guarantee is
low, i.e., the identity has not been verified).

I think on this issue it is just a matter of somebody putting things
together into a draft. I think Dean and/or Adam were the main initiators
of this proposal - something like a source=pstn parameter. Would
somebody care to author a draft? Or do we need further discussion?

John
_______________________________________________
Sip mailing list  https://www.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: Hannes Tschofenig <[email-masked]>
Date: Fri, 04 Apr 2008 11:50:49 +0300

I would instead not put the SIP Identity header there.
No additional work needed.

Ciao
Hannes

---

From: "Fischer, Kai" <[email-masked]>
Date: Fri, 4 Apr 2008 11:01:21 +0200

Hi Hannes,
what's than your recommendation how to handle SRTP (based on DTLS-SRTP)
for calls originated from PSTN and transferred to IP?
-Don't allow SRTP for such calls and fall back to RTP
-Allow SRTP, but don't protect the certificate fingerprint

Kai

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Hannes Tschofenig
> Sent: Freitag, 4. April 2008 10:51
> To: Elwell, John
> Cc: [email-masked]
> Subject: Re: [Sip] RFC 4474 and PSTN
>

---

From: Dean Willis <[email-masked]>
Date: Fri, 4 Apr 2008 04:01:20 -0500

> No additional work needed.

Well, the problem is that you do apparently gain some benefit from the  
presence of the Identity header when used with DTLS-SRTP.

The DTLS-SRTP draft says:

> The certificate fingerprints are sent in SDP over SIP as part of the  
> offer/answer exchange. The SIP Identity mechanism [RFC4474] is used  
> to provide integrity for the fingerprints.

So, to the extent that fingerprint integrity is useful, RFC 4474  
identities are useful even when the assertion of identity is not strong.

--
Dean

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 04 Apr 2008 12:06:38 +0300

I wrote that text in the DTLS-SRTP framework document and when I wrote 
it I did not think about E.164 number usage.

As mentioned at the last meeting a bit more detail about the different 
use cases needs to be written. .

I don't think that there is a lot (if any) benefit of using SIP Identity 
when the call comes from the PSTN.

Ciao
Hannes

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 04 Apr 2008 12:09:00 +0300

> -Allow SRTP, but don't protect the certificate fingerprint
That's what I would do.

Ciao
Hannes

>>> There seems to be some interest in adding some indicator to 
>>>       
>> the URI or
>>     
>>> to the header field to warn of the limited guarantee of 
>>>       
>> authenticity or
>>     
>>> the opposite (i.e.,lack of such an indicator would mean the 
>>>       
>> guarantee is
>>     
>>> together into a draft. I think Dean and/or Adam were the 
>>>       
>> main initiators
>>

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 04 Apr 2008 12:17:02 +0300

There are actually two things that could be reasonable:

* Use SRTP but without DTLS-SRTP (just use SDES in this case)
* Use SRTP with DTLS-SRTP but without protecting the fingerprint. Hence, 
SIP Identity would not be used.

Ciao
Hannes

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 04 Apr 2008 10:13:10 +0100

Hannes,

Personally I think there will be occasions when knowing that media is
secured as far as a known PSTN gateway can be useful, so signing by the
gateway I think can still have some value. One way to achieve this would
be with an email-style SIP URI for the gateway. So I guess the questions
are:

1)Whether there is any value in a gateway signing with an E.164-based
SIP URI, e.g., sip:[email-masked];user=phone, and if so
whether this needs a qualifier such a source=PSTN.

2) Whether there is any value in a qualifier such as source=PSTN even in
the absence of an RFC 4474 signature.

John

> From: Hannes Tschofenig [mailto:[email-masked]] 
> Sent: 04 April 2008 09:51
> To: Elwell, John
> Cc: [email-masked]

---

From: Michael Thomas <[email-masked]>
Date: Fri, 04 Apr 2008 09:11:49 -0700

> low, i.e., the identity has not been verified).

Versus the limited guarantee of authenticity of rfc4474 generally?
Let's be clear here: rfc4474 (like rfc4871) is a domain level "I
take responsibility" kind of mechanism. It is not any strong proof
that the local part is who it says it is. A receiver should always be
at least somewhat skeptical.
> somebody care to author a draft? Or do we need further discussion?

This seems like a slippery slope here. There may plenty of other reasons
that the local part might not be trusted besides being routed from the
PSTN.

So let me ask: what problem are we trying to solve and for whom?
And lets keep in mind the skeptical receiver.

       Mike

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 04 Apr 2008 18:10:05 +0100

Michael,

The proposed indicator is probably better described as "not verified"
rather than "limited guarantee of authenticity". But maybe, as has also
been suggested, we simply should not use RFC 4474 on requests from a
PSTN gateway.

John 

> From: Michael Thomas [mailto:[email-masked]] 
> Sent: 04 April 2008 17:12
> To: Elwell, John
> Cc: [email-masked]

---

From: Michael Thomas <[email-masked]>
Date: Fri, 04 Apr 2008 11:20:30 -0700

> been suggested, we simply should not use RFC 4474 on requests from a

Rather than work on a solution, I'd rather hear why a receiver cares
about any of this. Ie, what does the consumer of this information do
differently? The experience from the email world thus far is "not much"
which makes me suspicious this is too abstract a problem for the outside
world to care about.

A far more important question to be asking IMO is what will drive
4474 _deployment_, rather than adding bells and whistles to it. Until
there's something of a critical mass then it's pretty much just speculation
about the real life concerns.

       Mike, who's ecstatic that 7% of domains are dkim checking now
         but still doesn't think we know a lot about the evaluation of 
the localpart

---

From: Dean Willis <[email-masked]>
Date: Fri, 4 Apr 2008 13:34:56 -0500

> which makes me suspicious this is too abstract a problem for the  

That's a fair question.

The worry is that an RFC 4474 identity assertion forms what is  
essentially a contract verification "I, identity service example.com,  
have verified according to best current practices that the party  
originating this message is authorized to use the identity sip:[email-masked] 
".

We generally assume the "best current practices" something on the  
order of "the party in question has presented credentials based on a  
secret known to sip:[email-masked] and presumably unknown to other  
parties, and this presentation is consistent with prior interactions  
had by this identity service and sip:[email-masked]".

But when the identity assertion is coming from a PSTN caller ID, it's  
significantly less authoritative statement: "I, the identity service  
at example.com, think that this request came from +12142821376 because  
this is the calling party identifier presented to my telephony  
interface."

There is a profound liability distinction between these two. Failure  
to resolve it means that RFC 4474 identity headers would never be more  
credible than PSTN caller-ID, and we seem to think they need to be  
more credible.

> about the real life concerns.

Of course it will be driven be legal requirements around call- 
traceability, logging (especially in the financial services business)  
and intercept. Nobody cares about spam.

--
dean

---

From: Cullen Jennings <[email-masked]>
Date: Fri, 4 Apr 2008 12:35:46 -0700

> somebody care to author a draft? Or do we need further discussion?

I think more discussion is needed of what we want to accomplish before  
we can sort out what mechanism are needed. There seems to be a wide  
range of assumptions about what we want.

Culle <with my individual contributor hat on>

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 4 Apr 2008 15:50:23 -0400

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Elwell, John
>

I haven't thought about this since it was last on the list, and I think I was a proponent of it at that time, but why were we thinking this would ever be set?  I mean if I'm a clid spoofer, why would I ever want to add such a param??  Isn't it like a "spam=yes" flag you're describing, and then expecting potential spammers to set it?  I've forgotten the train of thought which lead to this param as a viable solution.

> of this proposal - something like a source=pstn parameter.

Or just source=evil. ;)

-hadriel

---

From: Dean Willis <[email-masked]>
Date: Fri, 4 Apr 2008 15:39:28 -0500

On Apr 4, 2008, at 2:50 PM, Hadriel Kaplan wrote:
> I haven't thought about this since it was last on the list, and I  
> think I was a proponent of it at that time, but why were we thinking  
> this would ever be set?  I mean if I'm a clid spoofer, why would I  
> ever want to add such a param??  Isn't it like a "spam=yes" flag  
> you're describing, and then expecting potential spammers to set it?   
> I've forgotten the train of thought which lead to this param as a  
> viable solution.

The Identity header essentially signs the From. It's traceable back to  
whoever made the signature. So, if you were an identity server, you  
could spoof any kind of caller ID you might want. But we'd know it was  
you doing it . . .

What we're looking for is a way for an RFC 4474 identity server to say  
something about how strong it believes its assertion to be. Sure, it  
could lie, but then we wouldn't trust it in the future. It's much  
better if it volunteers the information to us that it doesn't REALLY  
know who the caller is, since it has only the caller-ID information to  
go from.

If an identity server were to fully RFC 4474 "sign" a message rom a  
PSTN, it's even possible that the identity server operator could be  
held legally liable for inaccuracy in the asserted identity. In other  
words, if a caller-ID spoofer made a call through the example.com  
gateway, and the example.com identity server attaches an Identity  
header on to the resulting INVITE that asserts the spoofed telephone  
number identity, then someone injured (defrauded) by the caller could  
claim negligence on the part of the example.com identity server and  
sue for damages.

This is why things like identity servers (and CAs) have statements of  
policy that describe their procedures and the strength of claim being  
made. Those published policies are legal contracts with the users of  
the certificates. It's part of why x.509 certs are so big and have so  
many things like subject-alt-names and extended key usage. SIP  
identity services need the same sorts of legal flexibility. Being able  
to sign a request on the basis of "I swear to you that it came through  
my gateway, but I don't know who it really came from, so I make no  
assertions about this identity other than that the request came  
through my gateway with the calling-party-ID information described  
herein" is really, really important.

--
Dean

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 04 Apr 2008 18:07:06 -0400

There is a difficult line to walk here:

On one hand the GW operator doesn't want to be held liable for asserting 
an address it can't verify.

OTOH the UAS (should) want *some* assurance of the identity of the 
caller before displaying it as caller id.

If the UAS won't display without a trusted signature, and the GWs won't 
provide a signature for anything from the PSTN, then sip phones won't 
ever get callerid for calls from the PSTN.

If the UAS on the open internet will display anything (e.g. From) 
without any verification information, then I think we will, in a 
practical sense, have something that is far worse than the PSTN is 
today. (Maybe not worse than the PSTN will be when we have more IP 
interconnects with it.)

	Paul

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 4 Apr 2008 19:15:02 -0400

> From: Dean Willis [mailto:[email-masked]]
>

I'm pretty sure that's not possible.  It's possible to sue the good guys, in the local country - but it's quite hard if not impossible for me to sue some enterprise in Thailand, for example.  I don't know if verisign/thawte/etc. would give them a cert, but since we're not mandating specific "SIP 4474" certs and they can use the domain cert they legitimately got for web, I don't see how my UA is to know any better about their's than softarmor.com's cert. (without whitelists)

But more importantly, if you're thinking these things would truly have *legal* ramification, then my guess is no "good-guys" would touch signing with 4474 with a ten foot pole, ever.  Do DKIM email signatures have such legal implications?

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 4 Apr 2008 19:30:55 -0400

> From: Paul Kyzivat [mailto:[email-masked]]
>

Yes, very.

> caller before displaying it as caller id.

But I think that's the rub - people are pointing out that a PSTN Gateway doesn't have that assurance of the CLID it got to begin with.  Garbage in = garbage out.  I don't disagree there is a pragmatic middle-ground though. (the reality is the CLID's correct 99%+ of the time)
I'm just trying to figure out how in SIP it wouldn't quickly be worthless.

> ever get callerid for calls from the PSTN.

Sure, but it's the first antecedent I don't think holds: it just needs to display it differently, like with a "?" at the end or some such.  I know, I'm dreaming. :)  This problem sucketh.

-hadriel

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 4 Apr 2008 16:53:05 -0700

> But more importantly, if you're thinking these things would 
> truly have *legal* ramification, then my guess is no 
> "good-guys" would touch signing with 4474 with a ten foot 
> pole, ever.  Do DKIM email signatures have such legal 
> implications?

The closest analogy in DKIM would be someone that operated
a T.37/RFC2305 gateway (which converts fax to email), and
sends those resulting emails with their domain (example.com).

-d

---

From: Michael Thomas <[email-masked]>
Date: Fri, 04 Apr 2008 16:57:18 -0700

Dean Willis wrote:
> originating this message is authorized to use the identity 
> sip:[email-masked]".

Is 4474 really that emphatic? Can you point me to the section that defines
that (sorry, I'm not being rhetorical). That's a pretty high barrier, 
and strikes
me as a very hard thing for any bulk signing service to guarantee. DKIM
is far weaker.
> had by this identity service and sip:[email-masked]".

That puts an awful lot of responsibility on the signer, especially if the
signer isn't colocated with the credential verification.  With DKIM, we
do not make that kind of guarantee; it's up to the domain itself to
determine what the best practices are which might be some cryptographic
guarantee (say, SMTP auth), or might be layer 8 guarantee ("you'll
lose your job if you do this"). By not making any explicit guarantee
about the authorization to use a given local part, we skate around
this thorny issue and frankly makes it a lot easier to roll out a signer.
> this is the calling party identifier presented to my telephony 

Why is this limited to just the PSTN? Given your average megacorp or 
telephant,
the possibility for spoofing of the local part seems pretty significant 
when you're
talking about bulk signers. Weakening the guarantees to "you can complain
to my SIP admins" is a lot easier to achieve in real life.
> credible than PSTN caller-ID, and we seem to think they need to be 

I don't buy this: PSTN caller id is a cross domain transitive trust model.
4474 limits this to domain boundaries. That people want to put e.164
like thingies in the localpart doesn't change who controls the namespace:
it's the domain's, fullstop. Trying to go anything beyond saying that the
localpart is anything beyond an opaque blob as far as the receiver is
concerned is essentially saying that I want to tell you my rules for laying
out my name space, part of which has thingies that look (but aren't)
e.164 blobs.

I really don't think you want to go here. The complexity here is
enormous.

But I'm not sure that my question was answered though: what do you
expect a receiver to do differently? Are you thinking about human
factors on the UAS? Something else?

       Mike

---

From: Michael Thomas <[email-masked]>
Date: Fri, 04 Apr 2008 17:09:59 -0700

> But more importantly, if you're thinking these things would truly have *legal* ramification, then my guess is no "good-guys" would touch signing with 4474 with a ten foot pole, ever.  Do DKIM email…
IANAL, but I sure hope not. It's certainly not what we intended.

But I'm not convinced (yet) that this is what 4474 is trying to do.
And I'm definitely not convinced that just because something in
my namespace happens to superficially look like a e.164 address
that I'm bound to some different standard. Would a rot13 on the
e.164-like thingie be sufficient to avoid those legal implications?

I'm sorry, but the implicit complexity just makes my head hurt.

       Mike

---

From: Dean Willis <[email-masked]>
Date: Fri, 4 Apr 2008 19:11:44 -0500

On Apr 4, 2008, at 6:15 PM, Hadriel Kaplan wrote:
> I'm pretty sure that's not possible.  It's possible to sue the good  
> guys, in the local country - but it's quite hard if not impossible  
> for me to sue some enterprise in Thailand, for example.  I don't  
> know if verisign/thawte/etc. would give them a cert, but since we're  
> not mandating specific "SIP 4474" certs and they can use the domain  
> cert they legitimately got for web, I don't see how my UA is to know  
> any better about their's than softarmor.com's cert. (without  
> whitelists)

Dude, go talk to your lawyer.

I'm NOT talking about a foreign identity service that is the source of  
caller-ID fraud. I'm talking about an allegedly trustworthy identity  
service that is culpably negligent because it has allowed itself to  
become a conduit of identity fraud.

If you're  a US business, and you sign a a request containing a  
telephone number, and it turns out you're wrong (not because you're  
doing it on purpose, but because you are incompetent) and I get taken  
in by a scammer as a result of your mistake, I can sue you for all the  
damages I receive. I might even win, and at the very least, I'm going  
to cost you a big chunk of money.

But if you signed the request with a stipulation that you passed the  
request on, but that the identity came from the PSTN and is not  
something you have verified (and these things are true), then you are  
NOT liable, because there is no genenral expectation that PSTN caller  
ID is absolutely correct. You might also escape liability by very  
careful application of your published operations policy, but it's  
possible to run into the "implicit warranty" problem in some states.  
remember, this isn't criminal law, it's civil damages litigation,  
which has a much lower threshold of proof.

> But more importantly, if you're thinking these things would truly  
> have *legal* ramification, then my guess is no "good-guys" would  
> touch signing with 4474 with a ten foot pole, ever.  Do DKIM email  
> signatures have such legal implications?

Certificate issuance certainly has such legal ramifications. That's  
why there is a mass of policy documents around each of the CAs, and  
why you can't really trust a cert in the absence of understanding a  
CA's policies, and even then you can trust it only to the extent of  
the insurance and assets of the CA. And it's why you're more likely to  
believe a Verisign or other tier-1 CA's signing than you are to  
believe one from the Elbonian Secret Police -- because Verisign and  
the other Tier-1s have done the homework to both make themselves  
credible and manage their liability.

Even with this, I'm only describing the tip of the vast iceberg of  
legal complexity and liability that exist.

Given this, and in the absence a mechanism for making a disclaimer,  
you WOULD have to be a fool to slap an identity header on something  
that you didn't authenticate.

And yes, DKIM signatures can potentially have significant legal  
implications. The case law is generally undecided, but I expect it to  
be a lucrative area of practice for my attorneys.

---

From: Dean Willis <[email-masked]>
Date: Fri, 4 Apr 2008 19:15:17 -0500

> sends those resulting emails with their domain (example.com).

If you're an operator of a DKIM system, and somebody hacks your system  
and sends mail that's authoritatively from your domain, you can be  
held liable for the consequences of the email.  So could somebody who  
doesn't run DKIM and is hacked. But  bur position is actually weaker  
than someone who doesn't run DKIM, because you've made a stronger  
assurance of trust, effectively increasing your responsibility under  
implicit warranty.

---

From: Michael Thomas <[email-masked]>
Date: Fri, 04 Apr 2008 17:44:03 -0700

> assurance of trust, effectively increasing your responsibility under  
Anything is possible I suppose but this strikes me as rather alarmist.
Lots of big domains are running DKIM these days including some big old
banks who are usually pretty cautious about such things and ISP's who
have pretty awful control over their user base.  But we're not trying to 
vouch
for the authorization to use a given localpart either.

I'm pretty sure that if anything about this subject hinges on the likelihood
or not of future litigation we are in deep do-do.

          Mike

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 4 Apr 2008 17:54:10 -0700

> or not of future litigation we are in deep do-do.

Consider that, today, the opposite is true for the postal service,
the PSTN, ISPs, and email:  if you give them a letter, a phone 
number, a destination IP address, or a destination email address,
they are expected to route that letter, phone number, IP packet, or
email message accordingly.  There is a 'contract' to do so, and
a contract that they will not mis-route the letter, call, IP
packet, or email.

Similarly, when the letter, call, packet, or email is handed off
by the postal service, phone company, ISP, or email provider, it
has 'finished' doing its job.  Someone else in your house (or
place of business) might destroy the letter or mis-handle the
phone call.  Someone might drop the packet (your firewall, your
PC that crashed).  When the email is sitting on the email server,
someone might guess your password, login via POP, and retrieve
it without your knowledge.

DKIM, and rfc4474, do much the same, in reverse.

-d

---

From: Dean Willis <[email-masked]>
Date: Fri, 4 Apr 2008 20:07:36 -0500

> me as a very hard thing for any bulk signing service to guarantee.  

4474 provides a relatively strong assertion of identity. There isn't  
one place in the text that says it, but again and again throughout the  
text it covers potential weaknesses and why they aren't a problem. It  
talks about identities being "verified". My professional opinion is  
that, as written, RFC 4474, implies that the identity service has  
strongly vouched for the identity indicated in the header.

Consider the text of Section 5:

> This document defines a new role for SIP entities called an  
> authentication service. The authentication service role can be  
> instantiated by a proxy server or a user agent. Any entity that  
> instantiates the authentication service role MUST possess the  
> private key of a domain certificate. Intermediaries that instantiate  
> this role MUST be capable of authenticating one or more SIP users  
> that can register in that domain.

This normatively states that the authentication service can  
authenticate the users for which it voices, with the strong  
implication (supported later in the text) that it actually does so.

Consider also the discussion of trusted entities:

> One solution to this problem is to use 'trusted' SIP intermediaries  
> that assert an identity for users in the form of a privileged SIP  
> header. A mechanism for doing so (with the P-Asserted-Identity  
> header) is given in [12]. However, this solution allows only hop- by- 
> hop trust between intermediaries, not end-to-end cryptographic  
> authentication, and it assumes a managed network of nodes with  
> strict mutual trust relationships, an assumption that is  
> incompatible with widespread Internet deployment.

If you've represented yourself as a trusted provider of information,   
and arrange for people to trust that information, then you've entered  
into a contract to provide trustworthy services in a workmanlike  
fashion. If you do a shoddy job, you're liable for the consequences to  
your victims. This is true throughout legal systems derived from the  
British common law, including the US.  That's why every mutual fund  
you might buy has a prospectus saying "Past history does not guarantee  
future performance".

> this thorny issue and frankly makes it a lot easier to roll out a  

Right. But 4474 makes strong assertions about the user part.

And that's why we either have to choose to "take with a grain of salt"  
any Identity that contains something that might possibly be a phone  
number, or we have to have some way of differentiating things that  
came from the PSTN from those we really authenticated, or we have to  
follow the letter of RFC 4474 and NOT provide an identity header when  
there's any doubt. Several people have proposed this last choice, and  
it's technically valid.

But since DTLS-SRTP does get some benefit from having an RFC 4474  
header, this consequently weakens what we get from DTLS-SRTP whenever  
there's a call that originates on the PSTN and transits an IP network.  
This might be OK too, but if that's what we choose, then we have to  
document the limitation.

And so far, we keep going around in circles explaining the problem.  
And since we can't declare consensus on something people don't  
understand, we'll keep going around in circles until either 1) people  
get it, or 2) we give up.

> to my SIP admins" is a lot easier to achieve in real life.

Might be. But we've currently established the expectation that an  
Identity header serves to authenticate the calling party for access to  
confidential records like voice mail, access to conference calls, and  
so on. We can certainly go back and write in some guidance about the  
meaningfulness of the assertion, if that's what we choose to do.

> out my name space, part of which has thingies that look (but aren't)

Right -- the law is clear that as an identity server, you're  
responsible for the accuracy of your work, no matter whether the user  
part is numeric or textual or encodoes a phone number.

The question is, how do you avoid making misleading assertions?

Here's what 4474 already says:

> As a recipient of a request, a user agent that can verify signed  
> identities should also support an appropriate user interface to  
> render the validity of identity to a user. User agent     
> implementations SHOULD differentiate signed From header field values  
> from unsigned From header field values when rendering to an end-user  
> the identity of the sender of a request.

So yes, we expect the UAS to treat these things differently based on  
the presence of an Identity header. We could equally assume that it  
will treat them differently based on strength of the identity  
assertion. For example, one might choose to request a PIN from PSTN  
callers attending a conference bridge, but not do so from VoIP callers  
who have authorized identities.

--
Dean

--
Dean

---

From: Michael Thomas <[email-masked]>
Date: Fri, 04 Apr 2008 19:01:52 -0700

I have more to say here (sorry), but one thing leaps out at me:

> meaningfulness of the assertion, if that's what we choose to do.
Wait a minute: are we talking about cross-domain Identity being
used as credentials to access voice mail in another domain? Because
if it's only within a given domain's administrative control, it can know
the name space layout through out of band means. That is, it can know
if the names that it generates to gateway e.164 addresses are bogus
addresses to get at voice  mail, etc.

If it's the cross domain case, can you tell me the use case?

        Mike

---

From: Dean Willis <[email-masked]>
Date: Fri, 4 Apr 2008 22:32:50 -0500

On Apr 4, 2008, at 9:01 PM, Michael Thomas wrote:
>> Identity header serves to authenticate the calling party for access  
>> to confidential records like voice mail, access to conference  
>> calls, and so on. We can certainly go back and write in some  
>> guidance about the meaningfulness of the assertion, if that's what  
>> we choose to do.
>>

RFC 4474 is a cross-domain authenticator.

Use case:

sip:[email-masked] calls his voice mail provider's message  
retrieval box, sip:messages.example.net

Since example.net trusts example.com's RFC 4474 assertions, the  
voicemail box at messages.example.net does not authenticate JoeBobs'  
request. Instead, it accepts on trust that example.com authenticated  
him, and plays out JoeBob's messages.

This is AFAIK a valid use case for RFC 4474.

Now, assume JoeBob is instead named "[email-masked]". All of  
the above works fine, until somebody calls into example.com's PSTN  
gateway from a spoofed Caller-ID of "18005551212" and asks said  
gateway to connect them to messages.example.net

Here example.net needs to t be able to tell the difference between a  
call that originated on the IP network from 18005551212 and was  
properly authenticated (making a strong RFC 4474 assertion), and a  
call that originated on the PSTN and therefore has a weak identity  
assertion requiring further authentication.

--
dean

---

From: Hadriel Kaplan <[email-masked]>
Date: Sat, 5 Apr 2008 00:15:26 -0400

> to cost you a big chunk of money.

Yes, and you mistook my premise I think - I was not arguing about that for a US firm (heck, in the US you could sue even without a signature ;) - I was arguing about it for a foreign one.  Whether a US-based identity issuer (e.g., Verisign) has that liability for certs it gives out to foreign entities I don't know, IANAL, and isn't germane to my argument (I think).

> ID is absolutely correct.

Then everyone would set this source=unverified param, even those that have very reasonable expectation of it being legit, and we wouldn't get the semantic difference we're looking for.

> that you didn't authenticate.

Then I think anyone would have to be a fool to slap an identity header on anything, including things they authenticated.  SIP's trust model simply isn't HTTP's, even with SIPS and TLS and all.  It isn't even really the same as email's, though certainly closer.

-hadriel

---

From: Dean Willis <[email-masked]>
Date: Sat, 5 Apr 2008 12:08:15 -0500

On Apr 4, 2008, at 11:15 PM, Hadriel Kaplan wrote:
>> ...
> Yes, and you mistook my premise I think - I was not arguing about  
> that for a US firm (heck, in the US you could sue even without a  
> signature ;) - I was arguing about it for a foreign one.  Whether a  
> US-based identity issuer (e.g., Verisign) has that liability for  
> certs it gives out to foreign entities I don't know, IANAL, and  
> isn't germane to my argument (I think).
>

Ok, I'll buy that.

> Then everyone would set this source=unverified param, even those  
> that have very reasonable expectation of it being legit, and we  
> wouldn't get the semantic difference we're looking for.

The legal premise is "best current practice" -- you can't be  
absolutely sure in any case, but if you're such a doofus that you do a  
full RFC 4474 signature on something that we all agree can't be  
verified, then you may need to get slapped awake.

Unfortunately, the way RFC 4474 and DTLS Framework currently interact  
means that NOT using RFC 4474 on PSTN-sourced calls makes you almost  
as much of a doofus.

So we either change need to change RFC 4474 (by making a signature  
"mean less" OR by allowing one to make a disclaimer on the signature),  
or we change DTLS-SRTP framework to make it nod depend on RFC 4474 for  
end-to-end communication of the signature. We do have two drafts  
(Wing, Fischer) that would accomplish this.
> Then I think anyone would have to be a fool to slap an identity  
> header on anything, including things they authenticated.  SIP's  
> trust model simply isn't HTTP's, even with SIPS and TLS and all.  It  
> isn't even really the same as email's, though certainly closer.

Appropriate legal caution is required in all commercial practices. But  
blatant disregard for common sense will usually get you in trouble.

--
Dean

---

From: Dean Willis <[email-masked]>
Date: Sat, 5 Apr 2008 12:56:49 -0500

> (Wing, Fischer) that would accomplish this.

Sorry, I wrote too quickly and left out a bridge-construct, making the  
above more confusing than my usual rambling. And I misphrased a word  
or two. Sorry.

Let's retry:

So we either change need to change RFC 4474 (by making a signature   
"mean less" OR by allowing one to make a disclaimer on the  
signature),  or we change DTLS-SRTP framework to make it not depend on  
RFC 4474 for  end-to-end protection of the fingerprint.

We also have the issue of detecting fingerprint changes midstream,  
meaning that we've had a MITM on the media (that has replaced the  
Identity header). We do have two drafts  (Wing, Fischer) that would  
accomplish this.

The consequence of the second para above, if I understand it  
correctly, is that DTLS-Framework is relying on the RFC 4474 Identity  
header to protect the integrity of the key fingerprint which is  
transmitted in the SDP.  If the Identity header is UA-signed, this is  
pretty much rock-solid. However, if it is signed by an intermediate  
node, then it is possible that the intermediate node has altered the  
SDP (and fingerprint), and that it may be colluding in interception of  
the media. And that's just the way RFC 4474 works, so anything that  
relies on it (like DTLS-SRTP framework) has this limitation.

The point is that there may be a possibility to fix all these flaws in  
one pass. I'm not sure what solution would do this, but I have the  
feeling there's one out there that we just haven't quite identified yet.

The logic goes this way: DTLS-SRTP framework uses RFC 4474 for  
integrity protection of the fingerprint. By doing so it inherits  
weaknesses of RFC 4474. We have noted two of these as issues:

1) RFC 4474 cannot legitimately be used for calls originating on the  
PSTN and transiting a gateway to SIP because it lacks a way to inform  
the recipient that the From: field was not actually authenticated by  
the authentication service.  Otherwise said: as written, 4474 promises  
that the From: field was authenticated by the authentication service,  
and since in this case it wasn't authenticated, the service shouldn't  
be saying it was authenticated.

2) RFC 4474 headers may be subject to replacement by intermediates.  
While this might be required for certain uses of intermediates (such  
as SBCs that replace SDP because they're relaying it), it can also be  
used to insert an intermediary that intercepts the cleartext of the  
media (taps the call) without the consent of the endpoints.

We could work around by fixing these problems independently -- for  
example, by adding the From: disclaimer proposed by Adam and the  
assorted SBC-traversal and fingerprint preservation/verification  
techniques proposed by Dan, Kai, and probably others.

Or we could fix it by either fundamentally changing RFC 4474, or by  
providing a different fingerprint integrity mechanism for DTLS-SRTP  
framework and thereby breaking the dependency cycle.

--
Dean

---

From: "Elwell, John" <[email-masked]>
Date: Sat, 05 Apr 2008 20:23:42 +0100

Dean,

> Behalf Of Dean Willis
> Sent: 05 April 2008 18:57
> To: [email-masked] List
> signature),
[JRE] But isn't this effectively what the Wing and Fischer drafts are
doing, i.e., providing a different fingerprint integrity mechanism? They
would probably still need something like a PSTN disclaimer solution too.

John

---

From: Dean Willis <[email-masked]>
Date: Sun, 6 Apr 2008 03:09:21 -0500

On Apr 5, 2008, at 2:23 PM, Elwell, John wrote:
>>
>> On Apr 5, 2008, at 12:08 PM, Dean Willis posited:
>>>

It's a different thing to assert "this media goes with this  
INVITE" (when you sent both) than it is to assert "The identity we  
have authenticated as the source of this call is +19725199190" (when  
you don't really know).

The gateway service provider sending the INVITE is certainly  
responsible for the INVITE, so if they want to cryptographically  
assert that the RTP they're also responsible for is related to that  
INVITE, then I don't see that as a liability. Of course if they get it  
wrong they might have a problem, but that's just a cost of doing  
business -- and it's a lot easier to make assertions about something  
you control (the INVITE and the RTP) than about something you don't  
(the Caller-ID information).

In other words, if you're not asserting something as true that you  
reasonably have cause to expect may not be true, then you probably  
have no negligence, at least not of that type I've been talking about.

Do we need a special disclaimer for populating a From header field  
with a phone number? As this is the Best Current Practice, and since  
we've gone to some pains in the industry to say that an  
unauthenticated From:  is pretty much meaningless (see all the 3GPP  
sample calls from AlienBlaster), my opinion is no, we wouldn't need a  
disclaimer.

As for what the drafts actually do (do either Wing or Fischer  
completely eliminate a dependency on RFC 4474?), I'll leave that to  
the working group to figure out. Although it sure looks to me like  
that's what they're trying to do. :-).

--
Dean

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 07 Apr 2008 15:19:47 -0700

At Fri, 04 Apr 2008 11:20:30 -0700,
>        Mike, who's ecstatic that 7% of domains are dkim checking now

Hi Mike,

I was curious where you got this figure from...

Thanks,
-Ekr

---

From: Michael Thomas <[email-masked]>
Date: Mon, 07 Apr 2008 16:17:52 -0700

> I was curious where you got this figure from...
Ha ha,  I was wondering if anybody would notice :) It's from grinding 
through
our logs. It is between Cisco and other companies since the 7% doesn't
include cisco-cisco messages (it's 7% of domains we send to seem to vfy).
The bottom line is that it may be somewhat optimistic since the companies
who we correspond with might be more likely to be early adopters, but
then again, maybe it's not all that optimistic. I was pretty surprised.

       Mike

---

From: [email-masked]
Date: Tue, 8 Apr 2008 18:14:27 -0400

From: Hadriel Kaplan <[email-masked]>

   I'm pretty sure that's not possible.  It's possible to sue the good
   guys, in the local country - but it's quite hard if not impossible
   for me to sue some enterprise in Thailand, for example.  I don't
   know if verisign/thawte/etc. would give them a cert, but since
   we're not mandating specific "SIP 4474" certs and they can use the
   domain cert they legitimately got for web, I don't see how my UA is
   to know any better about their's than softarmor.com's
   cert. (without whitelists)

I think we're losing sight of the context...  *If* people who receive
calls actually care about authenticating the identity of callers via
SIP mechanisms (rather than by recognizing voices, or originating the
call themselves, etc.), then they're going to start depending on RFC
4474, etc.  And once they start depending on that, bad guys will start
trying to exploit that dependency, especially by exploiting identity
services that do not enforce identification effectively.  Indeed, we
can expect bad guys to set up identity services specifically for this
purpose.  At that point, people will discover the hard way that some
identity services are unreliable, so they will start whitelisting
identity services and/or CAs that reliably enforce reliability on
identity services.

The sort of reputation that has wide public trust will come to be seen
as a valuable asset, and identity services with that sort of
reputation (of which there won't be many) will charge signficant money
for their services.

Within that context, a PSTN gateway will not routinely apply
identification based on caller ID from an identity service which is
widely trusted - they can't determine the identity well enough, and
nobody is going to pay for it.

Now please excuse me, I have to go wire $10,000 to a government
officer in Nigeria who needs it to finance the payment of a legacy to
a distant cousin of mine.  (I can trust him, his From identity was
certified by the Nigerian government!)

Dale

---

From: Dean Willis <[email-masked]>
Date: Tue, 8 Apr 2008 19:40:38 -0500

> identity services and/or CAs that reliably enforce reliability on

I'm with you so far. Consequence: No "reliable" identity service will  
assert an identity with a phone number in it.,

But we NEED them to do so, otherwise we can't detect MITM attacks that  
affect both signaling and media.

catch 22.

> reputation (of which there won't be many) will charge signficant money

To whom? The user of the identity being authenticated, or the consumer  
of the authentication?

Note that "quality" certs today aren't cheap. I don't have one.

> nobody is going to pay for it.

So are you saying that the gateway's calls won't get Identity headers,  
or that they will, but they'll be signed using a bogus or less-trusted  
cert than would be used for calls originating from IP  terminals that  
support strong authentication?

> certified by the Nigerian government!)

Can you please ask him about Barrister James and the million he was  
supposed to wire me for my new startup? We're launching a SIP  
Authentication Service, "allur419srus.com". It will be widely trusted.  
But James hasn't called back since I advanced his legal fees.

--
Dean

---

From: [email-masked]
Date: Tue, 8 Apr 2008 23:05:13 -0400

From: Dean Willis <[email-masked]>

It seems to me that any identity mechanism of the sort we have been
discussing will be used only in specialized cases where strong
indentity assurance are needed and can be provided, and that it is
likely that gateways won't use it at all, nor will most organizations.

Dale

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 09 Apr 2008 00:24:22 -0400

Dale,

Suppose you are building a sip adapter for black phones. (Well, black 
phones with a callerid display.)

What criteria should it use before displaying the callerid of the 
incoming call?

It is restricted by hardware and convention regarding what it displays - 
generally just digits for the number. The customer is going to be upset 
if he just replaced a pstn phone, and isn't getting callerid from the 
same callers he used to get it from. OTOH, the phone is likely to be 
worried about trusting From - its just too easy to forge.

	Paul

---

From: "Dan York" <[email-masked]>
Date: Wed, 9 Apr 2008 10:27:46 +0000

+1

The reality is that while most of us may be aware that CallerID in the PSTN is easy to forge (and if you aren't, send me your number and I'll call you :-), the VAST majority of regular phone users actually *trust* the CallerID. So if a call comes in with the CallerID of your bank and you wind up talking to a very nice "representative", most folks will accept that as real. (I don't, but I am a paranoid security guy.)

SIP without strong identity just makes it that much more trivial to spoof CallerID. It's a wonderful playground for identity thieves, phishers, fraudsters and pranksters.

Dan
-- 
Dan York, CISSP, Director of Emerging Communication Technology
Office of the CTO    Voxeo Corporation     [email-masked]
Phone: +1-407-455-5859  Skype: danyork  http://www.voxeo.com
Blogs: http://blogs.voxeo.com  http://www.disruptivetelephony.com

Bring your web applications to the phone.
Find out how at http://evolution.voxeo.com

-----Original Message-----
From: Paul Kyzivat <[email-masked]>

Date: Wed, 09 Apr 2008 00:24:22 
To:[email-masked]
Cc:[email-masked]
Subject: Re: [Sip] RFC 4474 and PSTN

Dale,

	Paul

---

From: [email-masked]
Date: Wed, 9 Apr 2008 11:44:24 -0400

That there is a From header.

People have just argued at great length that PSTN caller ID is not
trustable, so displaying a From header has the same level of security.

Dale

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 09 Apr 2008 12:52:27 -0400

My concern is that accepting any old From and displaying the numeric 
part as callerid, will in fact lower the bar considerably from what it 
is in the PSTN today.

Of course I may be wrong about that. Perhaps the bar is already as low 
as it can go.

	Paul

---

From: Michael Thomas <[email-masked]>
Date: Wed, 09 Apr 2008 09:53:54 -0700

> This is AFAIK a valid use case for RFC 4474.

It's a _valid_ use case, but is it a _real_ use case? That is, is there
anybody out there using cross realm credentials in that way? Even
cellular isn't handled in that way because my sim is still with my
home provider even if I've roamed...

But even if that's the case, why would weakening the assertion
be useful? The two domains would obviously need to know quite
a bit about each other, so it's not clear to me why this
knowledge needs to be shipped inband.
> gateway to connect them to messages.example.net

So just don't sign it. Or sign it as @example.com. Or just tell the voice
mail provider not to create voice mail boxes for users with [email-masked]
like addresses. This really seems tenuous to me, Dean.

       Mike

---

From: Dean Willis <[email-masked]>
Date: Wed, 9 Apr 2008 23:17:38 -0500

On Apr 9, 2008, at 11:53 AM, Michael Thomas wrote:
>
>> Now, assume JoeBob is instead named "[email-masked]". All  
>> of  the above works fine, until somebody calls into example.com's  
>> PSTN  gateway from a spoofed Caller-ID of "18005551212" and asks  
>> said  gateway to connect them to messages.example.net
>>
>

I'm getting REALLY TIRED OF EXPLAINING THIS. Yeah, I know, one must  
say things ten time to be heard once. But this is eleven . . . ;-)

We need to sign it, because SRTP-DTLS relies on the signature in order  
to protect the fingerprint of the media key from MITM attacks.

In short, SRTP-DTLS requires RFC 4474 (for full function), and PSTN  
interaction precludes RFC 4474.

Something has to give. As I see it, we MUST pick at least one of the  
following:

1) Change RFC 4474 so that it can be used with phone gateways.
2) Change DTLS-SRTP so that it doesn't depend on RFC 4474.
3) Decide that we can live without integrity protection of the media  
key on calls transiting PSTN gateways, and document this.

We already have a strong argument for amending RFC 4474 so that SBCs  
that tweak the SDP don't break the Identity signature. If we do this,  
add the "not really an identity" flag, and mod DTLS-SRTP to account  
for the changes, then I think we have a full solution.

--
Dean

---

From: Ben Campbell <[email-masked]>
Date: Fri, 11 Apr 2008 13:56:25 -0500

> home provider even if I've roamed...

They don't now (or at least should not) because they don't have the  
tools for it. But if we give people a tool that appears to work for  
this purpose, we should expect them to use it for this purpose.

( I  am curious what existing PSTN voice mail systems would do if  
someone else called my voicemail and spoofed my caller ID).

Ben.

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 11 Apr 2008 17:45:07 -0700

> someone else called my voicemail and spoofed my caller ID).

When you call your voicemail system, if it asks for a PIN, that
is what someone spoofing your caller ID will get prompted with, too.

-d

---

From: Ben Campbell <[email-masked]>
Date: Fri, 11 Apr 2008 22:48:22 -0500

> is what someone spoofing your caller ID will get prompted with, too.

Many VM systems don't (or are commonly configured not to) even ask for  
a PIN if they think the caller is the mailbox owner.

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 11 Apr 2008 21:02:07 -0700

> Many VM systems don't (or are commonly configured not to) 
> even ask for a PIN if they think the caller is the mailbox owner.

Well, then you're hosed.  What is your voicemail number again?  I
was looking for it a few minutes ago, but I must have misplaced it.

-d

---

From: "Francois Audet" <[email-masked]>
Date: Fri, 11 Apr 2008 21:06:49 -0700

You are correct.

People are overestimating the security in PSTN.

---

From: Dean Willis <[email-masked]>
Date: Sat, 12 Apr 2008 04:16:55 -0500

> someone else called my voicemail and spoofed my caller ID).

Until several years ago, US voice mail systems were typically set up  
to not require PIN number entry when the caller ID matched the voice  
mail account.

http://www.geek.com/t-mobile-and-verizon-voicemail-open-to-caller-id-spoofing/

After a couple of high profile message compromise cases (if I remember  
right, somebody used a caller-ID spoof to retrieve Paris Hilton's  
voice mail, or maybe it was some other celeb's voicemail after Paris  
lost her Sidekick and the phone book was compromised), most of the  
providers reset the defaults to require PIN entry.

http://www.engadget.com/2005/02/20/paris-hiltons-hacked-sidekick-releases-unedited-tell-all/

http://www.computerworld.com/securitytopics/security/hacking/story/0,10801,99934,00.html

I think at least one carrier has gotten a workaround in place to user  
caller-ID as an authenticator, but only when the call is originating  
from a mobile in their network and they've handled the GSM  
authentication themselves.

---

From: Ben Campbell <[email-masked]>
Date: Sat, 12 Apr 2008 06:59:04 -0500

On Apr 12, 2008, at 4:16 AM, Dean Willis wrote:
>
> I think at least one carrier has gotten a workaround in place to  
> user caller-ID as an authenticator, but only when the call is  
> originating from a mobile in their network and they've handled the  
> GSM authentication themselves.

So to bring the conversation back to something vaguely relevant-- 
they've stopped trusting CallerID for interdomain (or intercarrier at  
least) authentication.

---

From: Ben Campbell <[email-masked]>
Date: Sat, 12 Apr 2008 07:08:44 -0500

> GSM authentication themselves.

Actually, I was contemplating an argument that we should just  
establish a best current practice that says one should never trust a  
phone number, even if it includes a 4474 signature, and that we didn't  
need to put anything in the message to indicate that. But you've just  
brought up an edge case where someone could really sign a phone number  
and mean it, that is, if the gateway is controlled by the  
authenticating carrier, it could have some out of band way of knowing  
about said authentication.  and could in fact trust the callerid with  
reasonable strength.

Therefore, the fact that the From header contains a tel (or  
user=phone) URL is not sufficient to for the receiver to infer the  
authentication strength.

---

From: Dean Willis <[email-masked]>
Date: Sat, 12 Apr 2008 13:17:45 -0500

On Apr 12, 2008, at 6:59 AM, Ben Campbell wrote:
> they've stopped trusting CallerID for interdomain (or intercarrier  
> at least) authentication.
>

1) The SIP Authentication Service described in RFC 4474 is not caller- 
ID. It is an authentication service -- more or less, the SIP  
alternative to Kerberos or Radius. One might well envision it as the  
solution to the problem that the mobile operators have with caller ID  
as an authenticator, and (should mobile operators use SIP) as the  
interdomain authentication tool of choice.

2) The problem is still that, since it is considered "string  
authentication" (not caller ID), RFC 4474 cannot reasonably be used  
for a call originating on the PSTN. But we require RFC 4474 be used on  
calls that need integrity protection of their media key for the IP  
path (which ideally would be all calls traversing IP paths).  
Consequently, we can not use the full benefits of DTLS-SRTP when the  
UAC is a PSTN gateway.

--
Dean

---

From: Dean Willis <[email-masked]>
Date: Sat, 12 Apr 2008 13:23:41 -0500

On Apr 12, 2008, at 7:08 AM, Ben Campbell wrote:
> phone number, even if it includes a 4474 signature, and that we  
> didn't need to put anything in the message to indicate that. But  
> you've just brought up an edge case where someone could really sign  
> a phone number and mean it, that is, if the gateway is controlled by  
> the authenticating carrier, it could have some out of band way of  
> knowing about said authentication.  and could in fact trust the  
> callerid with reasonable strength.
>

There's a much less "edge" case. It's entirely reasonable to have a  
phone identified by a phone number where that phone is attached to an  
IP network instead of the PSTN. ENUM could then be used to provide  
routing information to the phone. Such a phone could use strong  
authentication and encryption.

How, based on the From field (or any other information) can we  
differentiate such a phone from a PSTN gateway, consequently knowing  
when to trust and when not to trust the user part as signed by RFC  
4474? I've proposed in a separate message that "user=phone" be the  
differentiator -- in short, that PSTN gateways add "user=phone",  and  
that IP attached phones not add it.

The problem of course is backward compatibility. There are a few  
bajillion gateways out there that do not add user=phone. Consequently,  
were my proposal accepted, RFC 4474 could not be used with those  
gateways until they are repaired. I'm OK with that restriction.

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 13 Apr 2008 08:31:06 -0700

At Wed, 9 Apr 2008 23:17:38 -0500,

Dean,

I don't think that this analysis is correct.

First, you claim "SRTP-DTLS requires RFC 4474 (for full function)".
That's not quite correct, and I think it's worth walking through
the security analysis.

Let's start by looking at a simpler case, Web security. In the
classic Web security case, the server has a cert and the client
does not. At the completion of the TLS handshake, each side
knows the following:

- The client knows it has a secure connection to the server.
- The server knows it has a secure connection to *someone*.

There are two very important (in fact, the most common) cases
where this is precisely what you want:

(1) When the server does not care who the client is (for instance,
    in software download, where the client cares about getting
    an accurate copy but the server does not care who it gives
    copies to.)
(2) When the server has some other means of authenticating the
    client (for instance, when you're doing e-commerce and the
    client authenticates via password or credit card).

So, in these situations we don't ordinarily say that we're not
getting "full function" but rather that this is the design
goal.

Now, turning to the more complicated voice case. First, the the
fingerprint and RFC 4474 signature (and the RFC 4916 counterpart)
plays the same role here as does the certificate in the ordinary TLS
handshake, namely it provides authentication for one side of the
connection. It's quite possible to have a secure connection where only
one side is authenticated, so long as the authenticated side does not
care about the other side's identity. And there are a number of such
cases, especially in B2C settings. For instance, if I call Fidelity, I
care that I'm not talking to an attacker, but they only care that they
call not be hijacked, because they're going to ask me for a PIN
anyway. This is more or less how all PSTN-based security works
now, because you can't trust CNID. More on this later.

You write: 

This isn't quite correct. As long as one side verifies the other
side's identity, than MITM attacks get blocked, because an MITM attack
requires replacing keys in both directions with the attacker's
key. Consider the following example, in which Alice is calling Bob,
but for some reason her fingerprint isn't signed:

Alice                      Attacker                    Bob
----------------------------------------------------------
Fingerprint=X (unsigned) ->
                               Fingerprint=A (unsigned) ->
                               
                            <- Fingerprint=Z (signed, Bob)
<- Fingerprint=Z (signed, Bob)

So, Bob has no reliable way of knowing Alice's identity. However,
that's not sufficient to mount an MITM attack, which required that the
attacker to replace Bob's key Z with his own key A. But he can't do
that without replacing Bob's fingerprint, which would require the
ability to sign a message from Bob [0].

Now, let's turn to the PSTN case, the simplest of which is shown in
Figure 2 of draft-schwartz-sip-e164-ownership-01, namely, someone on
the PSTN calls someone on IP network. As has been widely noted, there
is no technical reason that the PSTN GW can't RFC 4474 sign the From
line, (though it's not clear what that means from the RP's
perspective), but even if the GW doesn't sign, we still have
significant security properties as long as it *verifies* the called
parties signature.  

Moreover, since the GW doesn't really know the
caller's identity (because you can't trust the PSTN identity
assertions) this is the best set of properties one could hope for, no
matter what SIP mechanisms we create. Even if there were some
mechanism by which the GW could say "I received this over the
PSTN and the CNID said X", and the relying party trusted the
RP not to lie, it still can't believe this assertion because
the GW's information is untrustworthy.

-Ekr

[0] But wait, you say. In SIP we don't have any restrictions on
who the call gets retargeted to, so the attacker could just send
his own key with a (valid) RFC 4474 identity pointing to his real
identity. This is absolutely true, and either Alice (or her UI
needs) to notice this, or we need a secure retargeting mechanism,
but this is a separate technical issue. The requirement right
now is that the right identity shows up in Alice's display, and
we get that right.
_______________________________________________
Sip mailing list  https://www.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: Hadriel Kaplan <[email-masked]>
Date: Sun, 13 Apr 2008 12:14:18 -0400

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Eric
> Rescorla
>

Agreed, but I don't think he's claiming his sentence as a fully qualified truism, but rather as a short-hand for: "We need one or both of RFC 4474/4916 to be used in common practice, and to sign the SDP, because without one or both of those mechanisms being used it allows a MitM to be a DTLS-SRTP middle-man."

> but for some reason her fingerprint isn't signed:

I don't think Dean is claiming a MitM attack is possible when 4474/4916 *is* used.  At least not in the definition of "MitM attack" where one side *thinks* it's secure but it's not.  Clearly a form of MitM attack can be trivially performed whereby neither side get signed requests, but still get fingerprints, but that's not a MitM attack in my book as much as it is a downgrade attack.  And that form of attack can be done on your example above, very easily, but then both Alice and Bob should know their media plane isn't secure.  And similar to TLS, Alice has to take care not to speak her PIN over the media plane to Bob, etc.

But I think Dean's point is: if we can't get a 4474/4916 model to be useful in practice, then *neither* side will be using it in practice.  We want it to be used in practice, as much as possible.  But he should chime in with what he meant. :)

Also, I'm not sure 4916 gives that "other direction" behavior.  It signs an upstream request, from the original UAS to the UAC.  It does not sign an SDP offer/answer from the UAS in the initial INVITE response, and thus does not sign the fingerprint, at least initially.

And even if 4916 is subsequently used, I think (though I'm not sure), that the UAS could well send the 4916 signature in an upstream request with no SDP, thus again not be signing the fingerprint.  (Although the correct thing to do may well be spelled out in Jason's draft, so maybe that's a nit)  And clearly that's not a fault of DTLS-SRTP fingerprint but rather of 4474 not providing a way for responses to be signed, and is a separate topic.

-hadriel

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 13 Apr 2008 09:42:17 -0700

At Sun, 13 Apr 2008 12:14:18 -0400,
Hadriel Kaplan wrote:

> I don't think Dean is claiming a MitM attack is possible when
> 4474/4916 *is* used.  At least not in the definition of "MitM
> attack" where one side *thinks* it's secure but it's not.  Clearly a
> form of MitM attack can be trivially performed whereby neither side
> get signed requests, but still get fingerprints, but that's not a
> MitM attack in my book as much as it is a downgrade attack.  And
> that form of attack can be done on your example above, very easily,
> but then both Alice and Bob should know their media plane isn't
> secure.  And similar to TLS, Alice has to take care not to speak her
> PIN over the media plane to Bob, etc.
>
> But I think Dean's point is: if we can't get a 4474/4916 model to be
> useful in practice, then *neither* side will be using it in
> practice.  We want it to be used in practice, as much as possible.
> But he should chime in with what he meant. :)

Well, I don't know what Dean is claiming, but what *I* am claiming
is that MITM attacks aren't possible as long as at least one side
uses 4474/4916 and the other side checks the signature. And that
means that at least in the case of PSTN->SIP calls, we don't
have an inherent MITM problem. 

-Ekr

---

From: Hadriel Kaplan <[email-masked]>
Date: Sun, 13 Apr 2008 13:41:09 -0400

> From: Eric Rescorla [mailto:[email-masked]]
>

Although unrelated to your general point above, the PSTN->SIP case seems a bit odd to me in practice, for two reasons:
1) What is it you expect a PSTN GW to do differently in these cases, vs. unsigned cases?  Since the PSTN GW has no way to pass on strength indications on the PSTN, do you expect it to automatically terminate calls which aren't 4916 signed?  Or play some announcement such as "this call is not secure"?  (and do we honestly think they'd do that?)  A downgrade attack is trivially possible, and leaves the PSTN GW with no idea if the called side could have actually done 4916 or not.  So should it just assume if it gets a fingerprint which isn't signed then there is probably a MitM?  (and also not do best-effort srtp offers)

2) You said in your email that the retargeting case is orthogonal, and that either Alice or her UI need to notice this.  But if a PSTN GW is representing Alice, I don't see how that's possible.  [this goes back to a previous thread] I'm not sure how a PSTN GW can know what the right domain for Bob's signature should be.  The PSTN GW only knows a phone number, period.  The 4916 signature may well be signed by a common trusted CA, but that really doesn't mean what it does in TLS, because there is no domain name verification possible to the PSTN GW.  In other words, the GW knows it's calling +123456789, and foo.com signed rfc4916 as sip:[email-masked], with a cert for foo.com.  The common CA did verify foo.com is truly foo.com, but so what?  The PSTN GW has no idea if the 123456789 at foo.com is the same global +123456789 that the PSTN meant to reach, or some legitimate open phone hosting service that happens to have usernames which collide with Fidelity's E.164, or even just another PSTN gateway.  In other words, what stops me (bad guy), from getting an account on foo.com with that number, and redirecting calls from PSTN GW to my account?

-hadriel

p.s. Personally, I think it very unlikely that PSTN-based calls will use DTLS-SRTP to begin with, simply because of the cost-benefit tradeoff.  But that doesn't stop me from wanting it to be possible, and more-so for 4474-type of signing to be possible for other uses.

---

From: Dean Willis <[email-masked]>
Date: Sun, 13 Apr 2008 15:25:20 -0500

> I don't think that this analysis is correct.

That's entirely possible. Thank you for helping sort it out.

> That's not quite correct, and I think it's worth walking through

... background elided

> now, because you can't trust CNID. More on this later.

Since the call has already been authenticated (4474 provides an  
"authentication service", no?)  Fidelity might well NOT ask you for a  
pin.

> but for some reason her fingerprint isn't signed:

Let's reduce this to what I see as the simplest use case: Alice calls  
Bob through a single domain proxy server that is also an RFC 4474  
authentication service.

Alice----->---PAS----->Bob

Typically, Alice sends an INVITE along with key fingerprint and normal  
SDP, PAS slaps authenticates her and sticks on an Identity header  
signing her INVITE, and sends it to Bob. Bob 200s with SDP and a key  
fingerprint. DTLS happens, Alice and Bob compare the key presented in  
DTLS with the key fingerprint sent in SDP, and everybody is happy.

But what if PAS were evil?

Alice sends an INVITE along with key fingerprint and SDP. PAS replaces  
the fingerprint and SDP pointing PAS, than adds an Identity header.  
Bob received the INVITE, responds with a 200 OK with his own SDP and  
fingerprint. PAS also replaces the SDP and fingerprint in the 200 OK.  
Next, Alice and Bob each independently DTLS handshake with PAS, while  
thinking they're talking directly to each other. The call has been  
intercepted, and the victim's don't know.

While the preceding isn't the use case for which DTLS-SRTP was built,  
it shows the simplest possible structure in which it can be subverted  
by A MITM that is abusing a position of trust. It's far more  
interesting to think about cases where a trust anchor hasn't turned  
evil.

Assume a more complex case, where each of Alice and Bob have their own  
PAS, and an evil proxy EP sits in the middle.

Alice------>PASA------EP------->PASB-----Bob

Here, Alice sends an INVITE with fingerprint and PASA signs it. EP  
passes the request to PASB, which passes it to Bob. Bob replies with a  
200 OK with fingerprint. Note that Bob's 200 OK cannot have an  
identity signature over that fingerprint, since RFC 4474 doesn't work  
on responses. PASB forwards this on to EP, which replaces the SDP and  
fingerprint. Alice then DTLS handshakes with EP, and is quite happy.  
Bob starts to handshake with EP, but since EP isn't in possession of  
Alice's cert, Bob detects the miskey and realizes the call has been  
intercepted. The protocol works against the attack, because Alice's  
fingerprint was integrity protected by PASA and could not be modified  
by EP.

But let's replace Alice with a gateway. This is basically the case  
from 8.4 of draft-ietf-sip-dtls-framework -- "Single-Sided- 
Verification" done backwards, with no integrity protection on the  
forward channel (GW to BOB). The 8.4 case has no verification in the  
other direction.

GW------>PASA------EP------->PASB-----Bob

GW sends an INVITE containing SDP and fingerprint to PASA. Since GW is  
a gateway, PASA cannot add an Identity header that provides integrity  
protection for the fingerprint. PASA forwards the request to EP. EP  
replaces the SDP and fingerprint ands sends it on to PASB. PASB sends  
the request to Bob, who generates a 200 OK with fingerprint and SDP  
then sends the request back to PASB. Since this is a response, PASB  
cannot add an Identity header. EP then replaces the SDP and  
fingerprint. and sends the response on through PASA to GW. GW and Bob  
then each DTLS handshake with EP, and the dirty deed is done.

Surely Bob could then offer connected-identity and send an UPDATE or  
reINVITE along with integrity protection back through the chain to A.  
EP could delay this or discard it, and by the time things have timed  
out, GW and Bob have been talking for a long time with their media  
intercepted.

While there are a lot of ways one could precondition this thing to  
death, the easiest fix is to eliminate this scenario by finding a way  
to apply integrity protect the initial INVITE from GW. The simplest  
approach I can see to doing that is to tweak RFC 4474 so that it can  
be applied to PSTN gateways. RFC 4474 in responses would also be  
darned useful.

> significant security properties as long as it *verifies* the called

As noted, the called parties' response can be altered by an evil proxy  
in the middle, since the fingerprint  in the 200 OK response isn't  
integrity protected by an RFC 4447 identity header (meaning there is  
no signature!). We can't rely on identity matching, since SIP's  
retargeting model is likely to throw the INVITE to just about anybody.  
So about all the GW can do is verify that the media key fingerprint  
matches the media -- but since the media key fingerprint can be  
altered by the attacker, the only reassurance GW has is that's it is  
talking securely to SOMEBODY, where SOMEBODY might be an attacker, or  
might be a legitimate retarget.

This is kind of like using single-ended TLS to secure HTTP when  
there's no requirement for a match between the certificate name in the  
response and the AOR. It doesn't work.

> the GW's information is untrustworthy.

But if we had a way to provide integrity protection over the  
fingerprint provided by GW, we'd be better off. This has nothing to do  
with identifying the original caller.

I see this as an unfortunate entanglement of the identity of the  
caller with the identity of the party generating the fingerprint. When  
there is a gateway involved, these identities DO NOT MATCH, but the  
current framework approach assumes they do (due to its use of RFC 4474).

> now is that the right identity shows up in Alice's display, and

The attacker doesn't have to send an RFC 4474 Identity header, because  
he's attacking the response, not the request, as far as the GW is  
concerned. And RFC 4474 doesn't protect responses.

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 14 Apr 2008 06:13:22 -0700

At Sun, 13 Apr 2008 13:41:09 -0400,
Hadriel Kaplan wrote:
> Although unrelated to your general point above, the PSTN->SIP case
> seems a bit odd to me in practice, for two reasons: 1) What is it
> you expect a PSTN GW to do differently in these cases, vs. unsigned
> cases?  Since the PSTN GW has no way to pass on strength indications
> on the PSTN, do you expect it to automatically terminate calls which
> aren't 4916 signed?  Or play some announcement such as "this call is
> not secure"?  (and do we honestly think they'd do that?)

Well, I don't actually expect them to do either, but that's fundamentally
not my problem. We're offering a higher level of security than the
PSTN is. If people making calls from the PSTN want to take advantage
of that, they'll need to do some ugly stuff.

>  A
> downgrade attack is trivially possible, and leaves the PSTN GW with
> no idea if the called side could have actually done 4916 or not.

That's not clearly true. As I understand the situation, when this
is *your* PSTN gateway, or at least has a relationship with you
so that it knows where to route calls to 1234. It's quite possible
it could know the capabilities of your proxy.

>  So
> should it just assume if it gets a fingerprint which isn't signed
> then there is probably a MitM?  (and also not do best-effort srtp
> offers)

That seems to me making the best the enemy of the good. There's certainly
value in unauthenticated encryption against passive attackers.

> 2) You said in your email that the retargeting case is orthogonal,
> and that either Alice or her UI need to notice this.  But if a PSTN
> GW is representing Alice, I don't see how that's possible.  [this
> goes back to a previous thread] I'm not sure how a PSTN GW can know
> what the right domain for Bob's signature should be.  The PSTN GW
> only knows a phone number, period.  The 4916 signature may well be
> signed by a common trusted CA, but that really doesn't mean what it
> does in TLS, because there is no domain name verification possible
> to the PSTN GW.  In other words, the GW knows it's calling
> +123456789, and foo.com signed rfc4916 as sip:[email-masked],
> with a cert for foo.com.  The common CA did verify foo.com is truly
> foo.com, but so what?  The PSTN GW has no idea if the 123456789 at
> foo.com is the same global +123456789 that the PSTN meant to reach,
> or some legitimate open phone hosting service that happens to have
> usernames which collide with Fidelity's E.164, or even just another
> PSTN gateway.  In other words, what stops me (bad guy), from getting
> an account on foo.com with that number, and redirecting calls from
> PSTN GW to my account?

And this has what to do with RFC 4474 or DTLS-SRTP? This is a pure
routing issue: the GW needs to know what proxy to contact for phone
number X. That configuration could (or could not) contain an 
indicator of whether 4916 is expected and what certificate should
be used. 

-Ekr

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 14 Apr 2008 09:28:10 -0400

Eric Rescorla wrote:
[snip]

> indicator of whether 4916 is expected and what certificate should

There's a difference between knowing a place to send the request so that 
it will eventually reach the right destination, and knowing the ultimate 
destination. There could be a *lot* of GWs, that typically are pretty 
dumb, and depend on some other routing element (e.g. proxy) to get the 
request to the right place.

You seem to be saying that the GW needs to know a lot more than that to 
secure the call. Far from ideal. Is that right, or am I missing something?

	Paul

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 14 Apr 2008 07:11:22 -0700

At Mon, 14 Apr 2008 09:28:10 -0400,
> request to the right place.

Yep. This is a fundamental issue of integrity for SIP call routing.

> secure the call. Far from ideal. Is that right, or am I missing something?

I agree it's far from ideal. There are two possible solutions to this sort
of problem:

- Some sort of authenticated history mechanism that gives the gateway
  confidence that the call was routed correctly
- Enough UI to tell the user who *actually* answered the call.

Unfortunately, the second isn't available here because of the lame PSTN
UI.

-Ekr

---

From: Michael Thomas <[email-masked]>
Date: Mon, 14 Apr 2008 08:45:42 -0700

> this purpose, we should expect them to use it for this purpose.

In the global scope of things, that's not completely true. You can use
certs and kerberos credentials cross realm theoretically, but the uptake
of that seems to be pretty minimal. What the real world seems to actually
think is useful is server certs and user passwords. Domain based federation
of sort-of-user-based credentials seems like a *very* big stretch.

       Mike, not saying whether the real world is sensible

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 14 Apr 2008 09:54:49 -0700

At Sun, 13 Apr 2008 15:25:20 -0500,
> "authentication service", no?)  Fidelity might well NOT ask you for a  

But that's exactly the point I'm making. Even if you *don't* RFC 4474 sign,
then Fidelity can ask you for a PIN, and this is still secure.

> But what if PAS were evil?

I don't understand the relevance of this use case: the basic premise
of DTLS-SRTP authentication (and of RFC 4474) is that the AS is
trusted. I don't merely mean that we rely on them; I mean that they
control the namespace. 

> fingerprint was integrity protected by PASA and could not be modified  

Once again, I think you're thinking about this as a DTLS-SRTP issue,
but that's fundamentally wrong. It's not about DTLS-SRTP at all,
it's about endpoint authentication.

At the completion of the SIP exchange (never mind the media) in
the above example, the parties have the following information:

- Bob knows he has received a call from Alice (authenticated
  by RFC 4474)
- Alice knows she tried to call Bob and got someone, but has
  absolutely no idea who.

If Alice wants cryptographic endpoint authentication of the called
party, she needs to insist on RFC 4916. Again, this has nothing
to do with DTLS-SRTP. It's just the logic of the SIP authentication
framework.

To see this, consider that even though Bob's UA has detected
the attack and hung up the phone, Alice is still talking to
EP and there is no cryptographic way for her to tell she's
not talking to Bob. 

Now, there are multiple ways to imagine implementations handling these
issues. One way is through UI. Bob's UA would be justified in putting
up some sort of "caller ID verified" icon linked to the RFC 4474
info. Alice's would have have an "unverified" icon. Another way would
be for Alice to instruct her UA that this call required 4916 and that
it should hang up if it didn't get it. (Admittedly, this would work
better if RFC 4474 could just be used with the OK).

> then each DTLS handshake with EP, and the dirty deed is done.

Where this has gone wrong is that it's not in fact single-sided
autentication: it's unauthenticated communication. Neither side
has required that the other side authenticate itself. So, of
course it's subject to MITM attack. 

> out, GW and Bob have been talking for a long time with their media  

It's not Bob's job to enforce this. It's Alice's, or rather her
UA's. It's Bob's job to do 4916, but Alice needs to check that
she's talking to the right person or else no security mechanism
can work.

> be applied to PSTN gateways. 

I have no idea what this actually means, but in any version of it
I can conceive, it doesn't do anything useful.

1. If Alice really cares who she is talking to, she *must* require
   authentication of the person on the other end of the connection,
   whether by 4916, an extended 4744, S/MIME, or by some alternate
   mechanism (e.g., PINs over the channel). Whether or not Alice
   sends her ientity to the other side or not is totally irrelevant
   to this question, as indicated above.

2. An RFC 4474 signature from the PSTN gateway doesn't do anything
   useful for Bob unless Bob can trust the *identity* claimed
   in that signature. Again, this isn't about DTLS-SRTP, but
   purely about the semantics of the PSTN.

   Say, for the sake of argument, that Alice's GW *did* sign
   with [email-masked]. This stops EP from changing
   the fingerprint while retaining the signature, but it just
   inserts its own fingerprint, changes the identity to
   [email-masked], which it does own, and resigns. The
   problem here is that Bob has no way of a priori knowing that
   there is any important difference between these two identities,
   and so he's not really doing endpoint auth. 

   Note, however, that this is a consequence of only looking at
   the LHS. If Bob's UA was configured to show "Alice"
   for [email-masked] and "Unknown" for [email-masked]   
   (e.g., via an address book) then this would all work fine.

So, absent some way for Bob (the RP) to know which AS should be
signing a given E.164 number, I don't see any useful change to
RFC 4474 that helps against this class of attack.

> RFC 4474 in responses would also be  
> darned useful.

I agree with that.

I'd like to just recap the basic security logic of authenticated
channels.

1. If both sides require the other side to authenticate, then
   integrity attacks are not possible.
2. If Alice requires Bob to authenticate but not vice versa,
   than an attacker can pose as Alice to Bob, but cannot
   pose as Bob to Alice. This is *not* a MITM attack because
   Alice cannot be attacked, only Bob.
3. If neither side requires the other to authenticate, then
   you can have an MITM attack.

Where I think your analysis is wrong is principally in two respects:

1. A verified attestation of a meaningless identity is not a useful
   form of authentication. Thus, it's useless for Bob to have a 4474
   signature from the PSTN gateway unless he knows that that E.164
   number can only be signed by that gateway. If he will accept as
   equally valid a signature from any GW (and importantly, treat those
   two entities as the same), then he is not in fact requiring
   authentication in any meaningful way.  Above, you're treating as
   single-sided authentication cases which really are unauthenticated.

2. If you, as one side of the conversation, wish to know who you are
   talking to, you need to enforce it yourself.  You can't get it as a
   side effect of offering your own credentials.

-Ekr

---

From: Alan Johnston <[email-masked]>
Date: Mon, 14 Apr 2008 14:04:03 -0500

Ekr,

Your analysis really misses the point others are making here.

This isn't a call between Alice and Bob - it is a call between 
+12125551212 and +19725551313.  If the identities of the two parties are 
telephony ones, then RFC 4474 does not provide the same integrity 
protection available to non-telephony SIP URIs, no matter how you spin 
it.  This is because without some new mechanism and protocol, there is 
no difference between an identity assertion of:

    sip:[email-masked]

or

    sip:[email-masked]

However, there may be a small MitM  difference.  And this is a DTLS-SRTP 
issue since it relies on integrity protection of RFC 4474 to prevent 
MitM attacks, and most VoIP endpoints in the world today use telephony 
identities.

Thanks,
Alan

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 14 Apr 2008 12:29:48 -0700

At Mon, 14 Apr 2008 14:04:03 -0500,
> Your analysis really misses the point others are making here.

If you say so.

> MitM attacks, and most VoIP endpoints in the world today use telephony 

Yes, I'm quite aware of the technical facts, I just believe you're
misinterpreting their import.

To reiterate what I said in PHL, the problem is *not* RFC 4474, but
rather the attempt to infer from a SIP URI with a numeric LHS that
you're in fact talking to someone with an E.164 number which matches
that LHS. Which is to say, that the relevant identity is not
+12125551212 but rather [email-masked]. If you work
in that space (and this of course can be hidden under UI in many
cases), then you in fact do get the appropriate security 
properties.

For calls which are coming from the PSTN, trying to go from the
SIP identity back to an E.164 number is basically meaningless.
No matter how strong we make our authentication infrastructure
on the VoIP side, the PSTN CNID information is untrustworthy.
We can't solve this problem by being extra-sure we only trust
some GWs to vouch for that information, since that GW has no
reasonable basis on which to base its assertion.

Now, if what you're concerned with is pure VoIP calls which
use E.164 numbers but don't transit the PSTN, then, yes, it's
potentially meaningful to talk about going from fully qualified
numeric LHS URIs to E.164 numbers. What you'd need is some
mechanism for determining whether a given domain should be
vouching for a given E.164 number. I've heard at least three
suggestions for this:

 - Manual lists of E.164 -> domain mappings
 - Enum
 - draft-wing style return routability checks.

I certainly think this is potentially worth pursuing, but as far
as I can tell, Dean was talking about calls transiting the PSTN,
where none of this stuff applies.

-Ekr

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 14 Apr 2008 12:30:02 -0700

> Behalf Of Eric Rescorla
> Sent: Sunday, April 13, 2008 8:31 AM
> To: Dean Willis
> Cc: [email-masked] List; Michael Thomas
> > > So just don't sign it. Or sign it as @example.com. Or 
> just tell the  
> > > voice

I think this analysis is optimistic regarding Alice's behavior.

Taking a less optimistic approach:

As shown in your diagram, Alice generates a message that is not
signed (due to misconfiguration or some other reason).  Due to
Alice's already-defective configuration, Alice may not expect
Bob's message to be signed, and thus the attacker could 
simply strip Bob's signature, replace Bob's a=fingerprint, and
successfully be a MitM.  Furthermore, Alice cannot assume that
Bob implements Connected-Identity, so Alice can't really assume
that Bob *will* generate a signature at all.  Or do we require
Connected-Identity in the DTLS framework, and require receipt
of that Connected-Identity-signed message before the call is
completed (using security-preconditions, perhaps)?

-d

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 14 Apr 2008 12:48:07 -0700

At Mon, 14 Apr 2008 12:30:02 -0700,
> completed (using security-preconditions, perhaps)?

I think you're making life much more complicated than it needs to be
for the attacker. The attacker can simply pretend to be Bob, not
generate a signature, and pretend he is only willing to speak RTP.

There are two issues that need to be disentangled here:

- What you display on your UI
- What causes your UA to terminate the connection

Given that at the initial deployment of this system the vast majority
of users will not have any cryptographic capability of any kind,
I would expect that most UAs will be willing to place or
accept phone calls with at least the following sets of people
(people who won't do any crypto, people who do RFC 4474 but
not DTLS-SRTP, people who will do DTLS-SRTP but without
RFC 4474 signatures, people who will do DTLS-SRTP with 
RFC 4474 signatures). The best we can expect is that the UI
will clearly differentiate these three cases so the user can
do something meaningful if they care. The only case where I
would expect the UA to automatically drop the call is if there
were some clear cryptographic failure, e.g., the fingerprints
didn't match.

At some point in the future once there is reasonable deployment,
then it may become reasonable for users to configure their 
endpoints to only place or accept phone calls from people who
do some level of crypto. I can imagine a number of reasonable
profiles, depending on what threats you were most concerned
with. But this seems clearly up to the individual deployment.

That said, it's clearly the case that if you want to be able
to verify the identity of the person you called, you're going
to need some RFC 4474-like thing from them, whether it's 4916,
4474 w/ outbound, S/MIME, or whatever.

-Ekr

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 14 Apr 2008 12:59:15 -0700

EKR wrote:

...
> I agree it's far from ideal. There are two possible solutions 
> to this sort of problem:
> 

A different take on a solution (aimed at ssh and self-signed HTTP
certificates) is discussed at:
http://www.cs.cmu.edu/~dwendlan/perspectives/

-d

> Unfortunately, the second isn't available here because of the 
> lame PSTN UI.

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 14 Apr 2008 13:04:44 -0700

At Mon, 14 Apr 2008 12:59:15 -0700,
> http://www.cs.cmu.edu/~dwendlan/perspectives/

I don't see how the technique described here can plausibly work
with SIP, given that they rely on probes from different locations
getting the same response, which is not a requirement for SIP.

-Ekr

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 14 Apr 2008 13:09:19 -0700

> getting the same response, which is not a requirement for SIP.

If there is only one entity that 'owns' an identity -- which is
absolutely the case with email-style URIs with SIP -- it would
work.

And with E.164, there should also be only one entity that 'owns'
a number.  If there are multiple, they are PSTN gateways and none
of them own the number at all.

-d

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 14 Apr 2008 13:11:47 -0700

> 4474 w/ outbound, S/MIME, or whatever.

I agree with all those points.  Thanks.

-d

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 14 Apr 2008 13:15:15 -0700

At Mon, 14 Apr 2008 13:09:19 -0700,
> absolutely the case with email-style URIs with SIP -- it would

I think we're taklking past each other. There are two issues:

- being able to determine whether a given entity should be able
  to assert "[email-masked]". Yes, one could use some 
  technique like the one described here to do that, but we
  already have a technique for that, described in RFC 4474,
  so I don't see an advantage.
- being able to determine whether the fact that my call to
  [email-masked] was answered by [email-masked] was OK.
  This can't be resolved in this way because the routing
  may depend on From.

-Ekr

---

From: "Hearty, John" <[email-masked]>
Date: Mon, 14 Apr 2008 14:22:21 -0600

>RFC 4474 that helps against this class of attack.

Bob does know which AS to trust for any E.164 numbers.  He signed up with a service provider that, from a PSTN standpoint, owns the PSTN number Bob uses for PSTN callers to reach his SIP endpoint.  Bob only expects calls from the PSTN to come from that service provider.  He can't trust any other GWs.  So if Bob's UA is configured with the list of GWs his service provider supplied and a policy to trust only those GWs, all we need now is the proposed identifier (such as user=phone) that says to lower your trust expectations for the user part of the URI because it came from a PSTN assertion.  Bob can then trust his connection is fully secured all the way to the PSTN GW but no further.

John

---

From: Dean Willis <[email-masked]>
Date: Mon, 14 Apr 2008 16:33:58 -0500

> trusted. I don't merely mean that we rely on them; I mean that they

It's there  as an example on what the responsibilities of the devices  
are and how the protocol functions.

> it's about endpoint authentication.

No, it's about using key fingerprints to determine whether or not an  
MITM has intercepted the media.

A fingerprint in the signaling is enough to detect a MITM who operates  
purely on the media path.

But a MITM may attack the signaling as well. We therefore integrity  
protect the fingerprint in the signaling using an RFC 4474 signature.

If you have a fingerprint that is not integrity protected, then an  
MITM who influences the signaling can introduce a media relay and  
intercept the media.

> - Alice knows she tried to call Bob and got someone, but has

I'm with you here.

> to do with DTLS-SRTP. It's just the logic of the SIP authentication

Right. But that's not the problem -- can either Alice or the party  
she;s talking to (who may or may not be Bob) detect that an attacker  
has tapped the call? With a  fingerprint, they can. Without a  
fingerprint, they can't. So if the attacker is able to influence the  
signaling to change the fingerprint, they can't.
> EP and there is no cryptographic way for her to tell she's

That's true. Of course, assuming we're only talking a "phone tap" and  
not an impostor, Bob could say "Gee Alice, it looks like we have no  
security on this line, so contact me by some other means" and hang up.  
Or Bob could employ an out-of-band mechanism to talk to Alice.

> course it's subject to MITM attack.

And that's exactly the scenario we get when a call comes from a PSTN  
gateway, because 1) we can't RFC 4474 sign a phone identity coming  
through an gateway, and 2) we can't RFC 4474 sign a response. There's  
no authentication at either and, and consequently no way to integrity  
protect the key fingerprint.

> she's talking to the right person or else no security mechanism

The questions of "who you are talking to" and "has a 3rd party  
modified the signaling between you and the party you are talking to"  
are independent.

> I can conceive, it doesn't do anything useful.

One could use security preconditions with connected-identity to  
establish no media flow until RFC 4474 identity exchange has occurred  
in both directions.

But it is MUCH EASIER To just allow PASA to put an Identity header on  
the call from the gateway.

>   purely about the semantics of the PSTN.

Not true. Bob's trust of the key fingerprint is based on his trust not  
of the identity presented in the From:, but on his trust of the  
identity creating the RFC 4474 Identity signature.

>   and so he's not really doing endpoint auth.

That presumes that Bob trusts signatures from ep.com. Does he have  
reason to so trust? Can he even validate the signature from ep.com?

Assuming that this fools Bob into accepting the call, will Bob and  
Alice discover the deception when he says "Gee, Alice, normally you  
call me from example.com. HAve you changed to a new provider?"

> RFC 4474 that helps against this class of attack.

Once again, all that Bob is really looking at here is the RHS,  
especially if he he's been told to ignore the LHS through some sort of  
flag.

>   single-sided authentication cases which really are unauthenticated.

Well, if Bob accepts signatures from just any old domain, he's  
certainly screwed.

>   side effect of offering your own credentials.

As I've repeatedly said, the problem is not in knowing who you;re  
talking to. It's in knowing whether somebody else is listening in.

--
Dean

---

From: Dean Willis <[email-masked]>
Date: Mon, 14 Apr 2008 16:46:09 -0500

> where none of this stuff applies.

I'm talking about calls coming from the PSTN and onto the Internet.  
For the part of the call that spans the internet, we wish to have  
privacy and integrity protection on the media channel.

For providing privacy and integrity protection on the media channel,  
we have DTLS-SRTP.

Privacy and integrity on the media channel are, it seems, dependent on  
at least integrity in the signaling channel. This is an advantage over  
SDES, which required both privacy and integrity in the signaling  
channel.

RFC 4474 is used to provide integrity on the signaling channel.

We've agreed that calls coming from PSTN gateways cannot initially use  
RFC 4474 (requiring RFC 4916). Therefore, their signaling is not  
initially integrity protected end-to-end (although hop-by-hop  
mechanisms, such as TLS, might be applied). Consequently, they are  
subject to MITM attacks that do not affect non-gateway calls.

What we're arguing about is whether or not anything can be done about  
this.

---

From: Dean Willis <[email-masked]>
Date: Mon, 14 Apr 2008 16:51:51 -0500

On Apr 14, 2008, at 3:22 PM, Hearty, John wrote:
> Bob does know which AS to trust for any E.164 numbers.  He signed up  
> with a service provider that, from a PSTN standpoint, owns the PSTN  
> number Bob uses for PSTN callers to reach his SIP endpoint.  Bob  
> only expects calls from the PSTN to come from that service  
> provider.  He can't trust any other GWs.  So if Bob's UA is  
> configured with the list of GWs his service provider supplied and a  
> policy to trust only those GWs, all we need now is the proposed  
> identifier (such as user=phone) that says to lower your trust  
> expectations for the user part of the URI because it came from a  
> PSTN assertion.  Bob can then trust his connection is fully secured  
> all the way to the PSTN GW but no further.

Exactly. And the "stacked" Identity header approach (that I think Jon  
Peterson proposed) allows Bob to transitively trust other ASes which  
are trusted by his AS, but that Bob may have no direct relationship  
with.

--
Deab

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 15 Apr 2008 00:05:04 -0400

> Well, if Bob accepts signatures from just any old domain, he's  

How is Bob to decide who to accept signatures from? It is presumably a 
function of the SPs of the people who call him. So are people just to 
say "I'll accept ATT, Verizon, and Sprint" and leave it at that???

> talking to. It's in knowing whether somebody else is listening in.

I buy into this, since it is often not too hard to convince yourself of 
who you are talking to by voice, manner of speaking, etc.

	Paul

---

From: Dean Willis <[email-masked]>
Date: Mon, 14 Apr 2008 23:46:28 -0500

On Apr 14, 2008, at 11:05 PM, Paul Kyzivat wrote:
> How is Bob to decide who to accept signatures from? It is presumably  
> a function of the SPs of the people who call him. So are people just  
> to say "I'll accept ATT, Verizon, and Sprint" and leave it at that???

It comes down to contractual liability. Who do I have reason to  
believe I can sue if the identity has been falsified? In simplest  
terms, this means "somebody with whom I have a contract", either  
formal and personal, or informal and general. An example of the first  
sort is a specific contract with a service provider. An example of the  
second sort is an implicit contract with a root CA whose cert's are  
included in my commercial OS's browser distribution.

Most likely, people will accept signatures from providers with whom  
they have contractual agreements to provide those signatures; in  
short, signatures from their service providers. I believe that they  
will also be willing to accept transitive signatures. By this I mean  
signatures that are initiated by some other service provider, with  
whom the recipient;s service provider has made contacts of mutual  
authentication.

So if I'm an AT&T customer, I'll accept an AT&T signature. Assume you,  
as a Sprint customer call me. Your call goes out with a Sprint  
signature. Would I trust this directly? Probably not. But if AT&T and  
Sprint have a deal by which AT&T is also willing to add their own  
signature attesting to their trust of Sprint's signature, I'll trust  
AT&T's signature even though it is being applied to a Sprint ID. Of  
course, I'd personally like to see BOTH signatures preserved, since I  
might have an independent agreement with Sprint that AT&T is not aware  
of.

Fewer people are likely to accept signatures of the second sort, and  
quite probably commercially-supplied software will not do so as a  
default. For example, I expect that if I buy a consumer phone from  
AT&T that it will treat signatures asserted by AT&T (or possibly by  
AT&T and other companies with whom it has contracted) differently than  
it will treat signatures by unrelated third parties.

As a user, I'm also more likely to respect signatures from firms that  
I know and do business with than ones from firm's I don't. That's  
called "reputation".

So for example, I might accept a signature from a Cisco Systems cert  
issued by Verisign for a call (although as a more-astute-than-average  
user, I might wonder if the topic of the call were unrelated to the  
business of Cisco Systems, for example it the caller claimed to be  
from my bank. But frankly, if I get a phish call from somebody who's  
using a Cisco Systems cert issued by Verisign, I probably have grounds  
for a lawsuit against Cisco anyhow.

> I buy into this, since it is often not too hard to convince yourself  
> of who you are talking to by voice, manner of speaking, etc.

It is also to differentiate the several levels of "who I am talking to".

For example, assume I as an AT&T customer get a call from some random  
phone number, through a gateway operated by AT&T. I don't really need  
to know the identity of the calling party to deal with media security  
issues and apply DTLS-SRTP. All I need to know is the identity of the  
operator of the gateway, because I'm concerned about detecting MITMs  
between me and that gateway. What happens on the other side of it is  
outside of my control.

For the typical case wherein I might rent a phone number from AT&T,  
where AT&T is the gateway operator of record for that phone number,  
all I need for SRTP-DTLS to work flawlessly (and provide full MITM  
control) is a signature that asserts an AT&T identity and covers the  
media fingerprint in the SDP.

EKR is quite correct that this is NOT the general case (although it is  
still a case that I think needs to be solved).

Let's consider a broader problem; perhaps it isn't my service  
provider's gateway that is sourcing the call. There might be many  
operators who provide an inverse-gateway service, where their PSTN  
users dial a fixed telephone number, enter a PIN, then enter a new  
destination number or use ten-key-spelling to enter my SIP username  
URI (example: sip:[email-masked]).

When such a request shows up at my phone with some random signature on  
it, how am I to know that this is the "original" signature or whether  
it has been replaced by by some signaling-and-media MITM? Answer: I  
can't.  If the source of the call (in this case a phone number) isn't   
cryptographically or contractually related to the domain of the  
signer, I have nothing to go on.

So if company A provides such gateway services to Alice, and Alice  
calls me, but company B intercepts her INVITE and replaces SDP,  
fingerprints, and Identity signature with a Company B signature, and  
given that I have no reason to expect Alice to have used company A  
instead of company B, then I can't detect the attack at all. I see  
that Alice called me from company B. Now, I might be able to ask Alice  
in-band "Hey, what company did you use to call me" and check for a  
mismatch. This is the "gateway" equivalent of the ZRTP-style  
fingerprint check. But we can't really expert normal people to do this  
consistently.

But back to "reputation:. If I think company B is a reputable gateway  
services provider, then I might well choose to believe their signature  
at least to the extent of using it to detect media-tapping MITMs, even  
if I didn't trust it to give me a real caller ID. It may not give me  
end-to-end security, but at least it lets me know if somebody between  
B and me has tapped the call.

And this gets back to the core of the argument: As a receiver of  
Identity headers, having such a header from a reputable signer is  
useful (for media integrity checks) even if the "username" part of  
that identity header is explicitly not trustworthy.

--
Dean

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 15 Apr 2008 08:35:50 -0400

Dean Willis wrote:
> It comes down to contractual liability. Who do I have reason to believe 
> I can sue if the identity has been falsified? In simplest terms, this 
> means "somebody with whom I have a contract", either formal and 
> personal, or informal and general. An example of the first sort is a 
> specific contract with a service provider. An example of the second sort 
> is an implicit contract with a root CA whose cert's are included in my 
> commercial OS's browser distribution.
> 
> Most likely, people will accept signatures from providers with whom they 
> have contractual agreements to provide those signatures; in short, 
> signatures from their service providers. I believe that they will also 
> be willing to accept transitive signatures. By this I mean signatures 
> that are initiated by some other service provider, with whom the 
> recipient;s service provider has made contacts of mutual authentication.
> 
> might have an independent agreement with Sprint that AT&T is not aware of.
> 
> default. For example, I expect that if I buy a consumer phone from AT&T 
> that it will treat signatures asserted by AT&T (or possibly by AT&T and 
> other companies with whom it has contracted) differently than it will 
> treat signatures by unrelated third parties.

I buy the "contractual" approach. But the logistics still seem fuzzy to 
me. I don't really expect that the phones are going to be presenting the 
identity of the signers, at least as a matter of course. The user 
interface will need to be much simpler than that to be useful to most 
people. So it would seem that the policy will need to reside in the 
phone or in the provider.

But that raises a new set of questions about the kinds of service we 
would like to see possible. Personally, I don't want to be trapped into 
buying my phones from my service provider. I remember the way it was 
when the Bell system was a monopoly and you had to rent your phones from 
them. And of course that is pretty much the way it is with cell phones 
in the US. And it sucks.

*Perhaps* it can be worked out in such a way tht you can buy your phone 
and configure it using some service that helps with the decisions and 
then leaves the phone to enforce them. But that requires some thought.

> As a user, I'm also more likely to respect signatures from firms that I 
> know and do business with than ones from firm's I don't. That's called 
> "reputation".
> 
> business of Cisco Systems, for example it the caller claimed to be from 
> my bank. But frankly, if I get a phish call from somebody who's using a 
> Cisco Systems cert issued by Verisign, I probably have grounds for a 
> lawsuit against Cisco anyhow.

Ah, the Willis vs Cisco case. How deep are your pockets?

> phone number, through a gateway operated by AT&T. I don't really need to 
> know the identity of the calling party to deal with media security 
> where AT&T is the gateway operator of record for that phone number, all 
> I need for SRTP-DTLS to work flawlessly (and provide full MITM control) 
> is a signature that asserts an AT&T identity and covers the media 
> fingerprint in the SDP.
> 
> 
> Let's consider a broader problem; perhaps it isn't my service provider's 
> gateway that is sourcing the call. There might be many operators who 
> provide an inverse-gateway service, where their PSTN users dial a fixed 
> telephone number, enter a PIN, then enter a new destination number or 
> use ten-key-spelling to enter my SIP username URI (example: 
> sip:[email-masked]).
> 
> it, how am I to know that this is the "original" signature or whether it 
> has been replaced by by some signaling-and-media MITM? Answer: I can't.  
> If the source of the call (in this case a phone number) isn't  
> cryptographically or contractually related to the domain of the signer, 
> I have nothing to go on.
> 
> So if company A provides such gateway services to Alice, and Alice calls 
> me, but company B intercepts her INVITE and replaces SDP, fingerprints, 
> and Identity signature with a Company B signature, and given that I have 
> no reason to expect Alice to have used company A instead of company B, 
> then I can't detect the attack at all. I see that Alice called me from 
> company B. Now, I might be able to ask Alice in-band "Hey, what company 
> did you use to call me" and check for a mismatch. This is the "gateway" 
> equivalent of the ZRTP-style fingerprint check. But we can't really 
> expert normal people to do this consistently.
> 
> end-to-end security, but at least it lets me know if somebody between B 
> and me has tapped the call.
> 
> Identity headers, having such a header from a reputable signer is useful 
> (for media integrity checks) even if the "username" part of that 
> identity header is explicitly not trustworthy.

IMO this discussion is starting to get to the heart of the issue.

That is to identify the kinds of identity service that would be useful 
to people and that we have the possibility of providing. Both conditions 
are necessary:
- must be useful to people (which implies it is comprehensible)
- must be feasible to deliver

	Thanks,
	Paul