Subject: [Sip] verifying identity of sender

From: Juha Heinanen <[email-masked]>
Date: Wed, 6 Oct 2004 11:30:29 +0300

i read draft-ietf-sip-identity-03 and noticed that in order to use it,
the domains must still have private/public certificates that are "valid
back to a trusted CA".

my domain tutpro.com has not purchased such certificate and i would bet
that the same holds true for a VERY large percent of all internet
domains.  as long as this is true, the proposed identity verification
solution may work in theory but not is practice.

when thinking about this, i started to wonder if it would be possible
for the UAS to verify the identity of the UAC from the domain via a few
sip requests, i.e., by breaking this requirement:

      User agents that receive identity assurances must be able to
      validate these assurances without performing any network lookup.

by the way, i don't think that this requirement holds true in the
proposed solution either, since the uas must acquire the certificate of
the signing domain, which may mean network lookup.

so how about a certificate free system where the UAS authenticates the
request with the domain by sending to the proxy of the domain a
verification request?  when the proxy receives the verification request
it challenges the UAC and then replies to the UAS.  comments?

-- juha

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

---

From: Dean Willis <[email-masked]>
Date: Wed, 06 Oct 2004 10:11:35 -0500

>it challenges the UAC and then replies to the UAS.  comments?
How would one authenticate the domain's proxy, such that a MITM could 
not substitute a proxy that would then falsely vouch for the UA?

The usual answer for this is "check the proxy's cert" which of course 
circles us back onto the original argument.

Other alternatives that might work would include something like a 
Kerberos model, but that leaves us with a problem of interdomain 
authentication which essentially boils down to the cert problem.

--
Dean

---

From: Juha Heinanen <[email-masked]>
Date: Wed, 6 Oct 2004 18:35:50 +0300

> not substitute a proxy that would then falsely vouch for the UA?

yes, my proposal doesn't offer 100 % security. but considering how much
you get, it would still be good thing to do.  very few sip users today
authenticate the proxy they talk to.  if that would be have been a
requirement from the start, we would have very little sip usage in the
first place.

-- juha

---

From: Dean Willis <[email-masked]>
Date: Wed, 06 Oct 2004 13:16:36 -0500

>requirement from the start, we would have very little sip usage in the
Why? It works for HTTP. You wouldn't think of buying from a web site, 
doing banking, stock trades, or anything else sensitive without looking 
for the little padlock icon, would you?  And if somebodody else did, and 
got ripped off, you'd laugh at them, right?. Well, I would, but you're 
probably a nicer guy and would just point out their security fault.

--
Dean

---

From: Juha Heinanen <[email-masked]>
Date: Wed, 6 Oct 2004 21:38:09 +0300

> probably a nicer guy and would just point out their security fault.

online shopping is very much different application than sip
applications.  when you sell something, you can justify going through
the trouble of buying a certificate (although i have heard that those
are available under very loose basis and don't really prove much), but i
don't see it a viable option for each sip proxy.  take email as an
example.  it is an old application and still very few email servers use
certificates to verify senders.

i just repeat that a certificate free identity solution would prevent a
very large percent of sip requests coming from faked senders.  it would
not protect against mitm attacks or dns hijacking, but those are much
more difficult things to do that simply faking the from field of the
request that is within the reach of anybody.  it would thus make more
sense to me to have a imperfect deployable solution rather than a
"correct" solution that very few can deploy.

-- juha

---

From: Dean Willis <[email-masked]>
Date: Wed, 06 Oct 2004 15:10:44 -0500

>"correct" solution that very few can deploy.

It seems this has a lot in common with the MARID email work, which as I 
recall tried two approaches:

1) Putting keying material into DNS that a domain server could use to 
"sign" outbound email, thereby proving it had come from that domain
2) developing a sort of "outbound" MX record for DNS that indicates 
authoritative sender relays for a domain, allowing receivers to verify 
(by address matching) that the message had at least come through a 
server in the indicated domain.

Both approaches are transitive trust models, with DNS dependencies, that 
vary by the strength of the trust mechanism.

If one wished to "water down" identity for deployability one could 
essentially use the 3GPP approach of P-Asserted-Identity combined with 
veryifying that the Via header contains an entry listed in DNS as an 
authoritative proxy for the domain asserted in the P-Asserted-Identity 
header field, and trusting that said proxy enforced identity. This is a 
little lighter than polling said proxy, but does slightly less about 
MITMs, as another proxy in the chain might have changed the P-Asserted 
-Identity header field value.

It may also be interesting to note that MARID apparently gave up in 
disgust at the patent situation.

--
Dean

---

From: Juha Heinanen <[email-masked]>
Date: Thu, 7 Oct 2004 08:21:59 +0300

> server in the indicated domain.

here nothing new needs to be put in dns.  when uas receives invite, it
gives back a provisional response, constructs the verify request
including a hash of invite's from uri, call id and from tag, and then
sends it out like any out-of-dialog request using the from uri as
request uri.  when the uac of the invite receives the verify request, it
checks if it has any pending invite that matches the hash and responds
either with 200 ok or some failure code.  when uas receives the verify
response it gives final response to the invite and that is it.

-- juha

---

From: Cullen Jennings <[email-masked]>
Date: Thu, 07 Oct 2004 08:26:48 -0700

If you want a free certificate, have a look at http://cacert.org

It sounds like the sort of scheme you discuss below would end up relying on
the security of DNS which, short of DNSSec, is not very good. Certificates
are not that hard to get but yes I agree they do take some effort. The
problem is, no one has proposed an alternative solutions that does not use
them and looks deployable.  The current identity scheme adds a little extra
work for the domain administrator and a close to zero cost. It does not add
any additional per end user cost or effort. This seems pretty good compared
to any alternatives that have been proposed.

Cullen

---

From: Cullen Jennings <[email-masked]>
Date: Thu, 07 Oct 2004 08:58:37 -0700

> response it gives final response to the invite and that is it.

ok so my from says if X send you a message, then X can receive your reply.
How does this help know who X is?

---

From: Dean Willis <[email-masked]>
Date: Thu, 07 Oct 2004 16:23:27 -0500

>How does this help know who X is?
Not quite.

I INVITE you to a call.  Upon sending the INVITE, my UA sends a PUBLISH 
to the softarmor.com server saying I really did send an INVITE to you, 
and including a hash of that INVITE. Hopefully, softarmor.com 
authenticates that PUBLISH message.

You get the invite, wonder if  it really came from someone who could 
authenticate as me to softarmor.com, poll that server (including the 
hash) and softarmor.com tells you "Yes, that INVITE came from somebody 
who could authenticate as Dean. Trust me."

So, the strength of the assertion of softarmor.com as to my identity is 
contingent on two things:

1) The strength of your belief that the server you think is 
softarmor.com really is (and isn't somebody else just faking)
2) The strength of your belief in the functional integrity and 
authentication provided by softarmor.com

In the simplest case, all that this technique proves is that whoever 
sent you the message is either 1)  authenticated to the asserting 
server, or 2) capable of munging DNS or IP routing to intercept your 
request to the asserting server, making them sufficiently interesting to 
talk to anyhow.

In the typical "dumb ISP" case, this is a weak assertion, but it's still 
much stronger than we get for email and would block the majority of 
source-fraud spam.

But in a confederated environment, where servers might have IPSEC SAs or 
be linked by private, protected network, the assertion could be a bit 
stronger.

Questions:

1) Is this imperfect solution so useful as to be worth specifying, even 
though we know it's not complete?

2) Is the benefit of the solution worth the additional 4 message 
overhead on every transaction?

3) Are there obvious  optimizations, such as having the asserting server 
"learn" about the request by observation rather than explicit notification?

4) Could we just use a MARID approach, and configure "edge" proxies to 
discard inbound requests where the source IP address doesn't show in DNS 
as authoritative for the domain component of the From: address, thereby 
getting most of the benefit with less overhead?

--
Dean

---

From: "Spencer Dawkins" <[email-masked]>
Date: Fri, 8 Oct 2004 06:42:26 -0500

> overhead on every transaction?

Dean/all -

2.a) is there anything that can be overlapped with this four-message 
exchange?

The calling party UA can immediately publish its hashed INVITE, and 
isn't waiting for the softarmor server's response to do anything - no 
delay there. But I'm thinking the called party UA couldn't advance to 
Alerting without getting the hashed response - am I missing anything?

I'm also thinking that an additional RTT from called party UA to 
calling party proxy would be more noticeable in wireless 
environments...

Spencer

---

From: Aki Niemi <[email-masked]>
Date: Fri, 08 Oct 2004 20:09:57 +0300

On Fri, 2004-10-08 at 00:23, ext Dean Willis wrote:
...snip...
> authenticates that PUBLISH message.

Uhh... I don't really want to nit-pick on this proposal, but this isn't
the intended use of the PUBLISH method [1].

I guess if your UA sent the INVITE first to softarmor.com's outbound
proxy, who in turn Digest-challenged for your proxy-authentication, then
no PUBLISH would be needed.

Cheers,
Aki

[1] From Abstract:

   ...
   The mechanism described in this document can be extended to support
   publication of any event state for which there exists an appropriate
   event package.  It is not intended to be a general-purpose mechanism
   for transport of arbitrary data, as there are better-suited
   mechanisms for this purpose.

---

From: Cullen Jennings <[email-masked]>
Date: Fri, 08 Oct 2004 11:28:48 -0700

ok, ignoring the syntax of the message, what you have is A and B are proxies
and A sends message to B with a token in it then B contacts A and verifies
this. This works as well as B can believe that it reached A and not the
attacker. 

Now consider the current identity proposal when A uses a self signed cert.
A adds hash and sends message to B. B contacts A to get the certificate. If
B decided to accept this certificate from someone that provides a self
signed cert it can. This is just policy about how well it wants to believe
it really is talking to B. I think that in this case, the identity scheme
reduces to exactly the same basic message flow and security properties as
your proposal below.

---

From: Dean Willis <[email-masked]>
Date: Sun, 10 Oct 2004 23:14:07 -0500

> the intended use of the PUBLISH method [1].

Absolutely true.

> no PUBLISH would be needed.

yes, that's true.

>    mechanisms for this purpose.

of course, one could certainly define an event package for "Pending 
Requests for Which I Might Need a Half-Assed Identity Voucher". Perhaps 
a modification of the UA State event package?

This does give rise to the question of "How do we evaluate the 
appropriateness of new event packages?" which I suspect we'll be asked 
to do over the next year or so. Something to think about, as many of the 
proposals I've heard for new event packages had even less merit than the 
strawman above.

--
Dean

---

From: Dean Willis <[email-masked]>
Date: Sun, 10 Oct 2004 23:24:38 -0500

> this. This works as well as B can believe that it reached A and not the

A simple two-party reverse validity check can be handled more readily 
with a null-poassword digest authentication request, as proposed on the 
list a few years back.

Actually, you need 3 parties to demonstrate the utility of Juha's proposal.

Assume A, B, and C where A and C are UAs, and B is a proxy normally used 
by neither, but authoritative for the domain of A.

A sends a message to C with a token in it, which C can then ask B to 
validate -- "Hey Dude, do you believe one of your people called A said 
this to me?"

> reduces to exactly the same basic message flow and security properties as

err, not exactly sure I follow the above, as you seem to have B using 
A's cert to decide whether it is talking to itself.

But the (relatively) important thing about this approach is that it does 
block attacks where somebody pretends to be A, but doesn't really have 
the wherewithal to either authenticate to B, or to subvert the mostly 
unprotected the B-C link. This is excatly the weakness that the majority 
of source-forged spammers use to deliver spam in today's world.

--
Dean

--
dean

---

From: Cullen Jennings <[email-masked]>
Date: Mon, 11 Oct 2004 16:08:08 +0200

inline ...

> with a null-poassword digest authentication request, as proposed on the

Hmm, I don't by the "handled more readily" part. I have looked at dial back
and I believe it is harder to implement, results in weaker security in all
cases, is not easier to deploy, and results in significantly higher load on
proxies. I know that at first glance it seems like anything that does not
involve PKI must be easier than anything that does but  I don't think it is
in this case. I will try and explain why later on in this email.
 
> validate -- "Hey Dude, do you believe one of your people called A said

Hmm suspect you often need another proxy that is authoritative for B to form
the dialog but never mind.
 
So the dial back proposal works something like  A first gets this token, on
a per call basis from B (it has to be per call to include enough in the
token to stop cut and paste attacks). So B gets token, and hands to C. C
does connection with B and verifies the token. Is that connection TLS
protected? 

Alternative call flow using the Identity mechanism falls into two cases, one
where B trusts A with B's private key. This would be the case for voice mail
systems, large gateways, conference servers, and such but not typically the
case for phones other than in domains with a very small number of phones.
Keep in mind this thread started around domains that were too cheap to get a
certificate from a well known CA.

If B trusts A, then A can insert the identity header, send the call to C. If
the cert is from a well known CA then CA then C can verify the identity of
the sender. Note number of messages involved was 1.

If B does not trust A, then A can send call to B using previous digest
credential and B can insert identity header and send call to C and C can
verify it. Message count 2.

If B does not have a cert from a well known CA, it can still do the same
things as before but C will need to fetch the cert from B. The *first* time
this happens we add a +2 to the message count but it can be cached for later
messages. 

> A's cert to decide whether it is talking to itself.

Hopefully I cleared this up somewhat in the example of above. If this is not
clear, then is is probably not clear to many people and we should spend some
time at the next IETF meeting discussing why it is unclear and how to get it
clear.  

> of source-forged spammers use to deliver spam in today's world.

You are correct that the proxy to proxy link is were most SPAM gets inserted
today but DNS dialback is not going to help this all that much (unless you
assume DNSSec). That is why the email folks are so interested in the MASS
working group which ends up with solutions very similar to SIP Identity.

As a side note on DNS Sec - some people feel that PKI with delegated signing
keys for every company failed because the big CAs were greedy. Perhaps they
were not greed and that's just what it costs to run a CA - either way my
argument stays the same. DNS Sec requires the people that run the top level
domains to delegate to the sub domains and not be too greedy. Unfortunately,
the companies that ran the CAs and the companies that will with run the DNS
Sec TLDs are, surprise, surprise, the same companies. They may change their
pricing but I believe they are just as likely to change their pricing on
delegated CA certs as they are on sub domain signing)

Dialback provides better security than nothing and does not require money to
be sent to any CAs. The Identity draft as written provides a way to
implement one thing and be able to simultaneously get a much better solution
that does use CAs and also be able to get a solution that is better than
Dialback and also does not require certificates from well known CA's.

The level of security offered by Dialback is ok for some. Mostly for people
that are willing to use no security but would like better as long as it cost
them nothing. Identity can provide this (including the no extra cost part)

People that need security better than none, usually need security well
beyond what dialback can provide. Identity can provide that too.

There is a large contingent of people that want real security available.
This includes encrypted integrity protect communications to the person you
think you are talking to. It's useless to have encrypted communications but
not know who it is encrypted to. Identity meets the needs of knowing who you
are talking to for this group of people and is much more deployable than a
S/MIME cert for every UA.

It's not clear to me what problem dialback solves that many deployments
would care about. Today the B-C links are very well protected as they mostly
run in IPSec tunnels between preconfigured links. The ones that are not all
preconfigured can use mutual TLS.

---

From: Dean Willis <[email-masked]>
Date: Mon, 11 Oct 2004 15:25:27 -0500

>does connection with B and verifies the token. Is that connection TLS
Doesn't have to be. Remember, the scenario we're working from is someone 
faking a sender address in their otherwise normal endpoint, without the 
ability (or requirement) of intervening in normal network operations or 
altering DNS for the domain in question.

>certificate from a well known CA.
Huh? I doubt Cisco is going to hand you the private key to their proxy 
so that you can use it to sign requests. Consequently we fall into the 
second case for all real deployments.

>this happens we add a +2 to the message count but it can be cached for later
Excellent point. If C trusts that B is authoritative for the domain of 
A, then C has as much reason to trust a cert delivered by B as it does 
to trust an assertion on A's behalf made by B. This obviates the need 
for dial backs (except, of course, for certificate revocation issues)  
for the life of the  cert, if we use an identity-assertion-by-signing 
approach.

Now, what does this get us that  just having C verify 1) That B is 
authoritative for the domain of A according to DNS, and that 2) that the 
request came from the IP address of B, according to DNS, to the extent 
that a TCP socket could from.

You're doing the same exact thing, when you have C trust DNS and the 
routing path to B in order to fetch the cert from B.

As far, as I know, all the crypto you've outlined falls back to 
assumptions that are just as supportable in the non-crypto solution I 
counter-proposed to Juha,  with a lot less CPU effort and network 
traffic required.

One different property is that both assertion-by-signing and 
assertion-by-dialback can be "checked" multiple hops down the 
router-chain, whereas assertion-by-source-address cannot. Is this 
critical for real-world deployments?

... section elided ...

>preconfigured can use mutual TLS.
Well, last week I tried to send an email to somebody at RoadRunner, who 
bounced the email because the netblock (PTR) delegation for the address 
of my mail server du jour wasn't right. It turns out it's REALLY 
difficult for ISPs to get this right. Certainly the B-C link between my 
email server and their email server isn't going to be IPSec protected 
anytime soon. But if they'd been able to just look at DNS and say 
"Whaddya know. That email DID come through the MX for softarmor.com", 
things would have been ok. We don't do that for mail, because many 
companies run diassgregated inbound and outbound mail servers, and MX 
records only describe inbound servers.

And once again, remember that this thread was started by somebody (NOT 
ME ;-) ) who runs a REAL SIP NETWORK, is impacted by this problem in the 
real world,  is looking for an adequate, deployable solution, and hasn't 
been able to make registered certs appear to be financially attractive.

--
Dean