Subject: RE: [Sip] verifying identity of sender

From: "Peterson, Jon" <[email-masked]>
Date: Mon, 11 Oct 2004 01:38:59 -0400

Dean,

Help me to understand your position here. Is it your position as WG chair
that we need to scrap the existing identity work, and begin anew along the
lines you describe below? Or would you like to pursue this work as a
separate work item?

Anyway, hypothetically exploring this line of thought, it seems that using
PUBLISH to inform your local server of the hash of the INVTE you've sent is
probably superfluous - why not just send the INVITE through the local
server, and have it act as a proxy (along the lines of Question 3 in your
original mail describing the scheme)? It can acquire whatever state it needs
to as the request passes (including generating or copying the hash).

If you don't do that, anyway, you prevent the domain from enforcing any
identity policies on requests before they are sent. While this isn't
strictly necessary for an identity system to operate, it does provide a
number of beneficial properties.

If you do just sent the INVITE through the local server, the only real
difference between sip-identity-03 and your approach is whether the local
server signs the hash with a cert or forces any verifier to do a dial-back.
In fact, this variety of dial-back is remarkably similar to the
authentication mechanism employed by Jabber. That much said, sip-identity-03
can also requires a dial-back, after a fashion, if the verifier does not
already have the cert of the proxy server.

So, once again, this is a question about how to provide a construct that
links a domain name to some sort of credentials: cryptographically with
certificates, or using the network with the DNS.

A couple of things to note, beyond the general weaknesses of using the DNS
already highlighted in this thread:

- There can be more than one consumer of the identity information in a
request; i.e., one or more intermediaries and/or the UAS might want to
verify the hash. If a dial-back is required, we pay the network cost on a
per-verifier basis. Of course, in sip-identity-03, if verifiers don't have
the cert of the domain, they'll pay the network cost anyway. However, each
verifier needs to pay that network cost only once per unique domain, not
once per unique message. This can quickly become meaningful, even in the
course of a single dialog.

- In order to dial-back (not to mention PUBLISH) securely, one should use
TLS. TLS entails the use of certs anyway, and requires the verifier to
download a cert. So, it's not clear to me that the cert costs won't be paid
anyway. Without TLS, anyway, you have to worry about more than just someone
who is capable of munging DNS or IP routing - passive attackers could quite
possibly confuse the verifier with forged responses to a poll to verify the
hash.

- This requires per-message state (i.e. the hash) to be maintained at the
local server (as your proposed use of PUBLISH exemplifies). Managing an
event database that changes for each message in your domain becomes
intensive pretty quick. Of course, sip-identity-03 requires state to be kept
at verifiers, in the form of certificates, but this is not per-message
state, nor even per-sender state - it's per-sending-domain state. Moreover,
for the most part this state is being kept where state belongs - in the UAs,
not in intermediaries.

Finally, let me add that the dial-back constraint in sip-identity-03
(deferencing the URI in the Identity-Info header to acquire the cert) is
artificial - it's not necessary for this mechanism use the network. The
originating UAC could of course include his domain's certificate in a
request with a "cid:" URI in the Identity-Info header indicating the MIME
body contain the cert. The UAC will know this cert, after all, because at
the very least it will learn it when it forges a TLS connection to the
authentication service. If we did this every time, there would never be any
need for the verifier to poll the network. Of course, it would also make
requests larger, and this is why the draft currently doesn't recommend the
practice. But the fact that you can do things this way without impacting the
strength of the solution shows, I think, the versatility of this approach.

Jon Peterson
NeuStar, Inc.

> -----Original Message-----
> From: Dean Willis [mailto:[email-masked]]
> Sent: Sunday, October 10, 2004 9:25 PM
> To: Cullen Jennings
> Cc: [email-masked]; Juha Heinanen
> Subject: Re: [Sip] verifying identity of sender
> 
> 
> Cullen Jennings wrote:
> > 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. 
> 
> 
> 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?"
> 
> 
> > 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.
> 
> 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
> 
> _______________________________________________
> 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
> 

_______________________________________________
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: Mon, 11 Oct 2004 15:02:53 -0500

>lines you describe below? Or would you like to pursue this work as a

My position is that exploring Juha's suggested approach through list 
dicussion may provide enlightenment. I have not taken a position as 
chair on the appropriateness of this work.

>to as the request passes (including generating or copying the hash).
This was previously suggested by Aki, and is inarguably true. It does, 
however, predicate sending the request through the proxy, which is not 
absolutely required to get the properties under discussion. In short, 
it's a useful optimization, but is no more revealing (and may, in fact 
obfuscate) the security properties being discussed in Juha's proposal, 
as I understand them.  This approach is roughly analogous to the 
lightweight alternative I proposed earlier, which is "accept no requests 
from an external domain unless they came directly from the IP address of 
a proxy that is authoritative for that domain according to DNS". Again, 
this is not perfect security, but if combined with TCP (or self-signed 
TLS) at least blocks the vast majority of source-addres forgeries as 
seen in the world of email.

>number of beneficial properties.
Right. These properties were explicitly not part of Juha's proposal, so 
I constructed a discussion framework that did not exhibit them.

>already have the cert of the proxy server.
I believe that is correct.

>course of a single dialog.
Quite true, and a strong argument indeed.

>possibly confuse the verifier with forged responses to a poll to verify the
That depends to a great extent on your definition of "secure". There is, 
in a practical sense, a significant difference between state-of-the-art 
(or state of the imagination, in some cases) security and "things that 
can be done very esaily and help prevent real problems." Since someone 
with paractical experience running a consumer network raised the 
question along with the argument that the identity approach might be 
difficult for them to deploy, it seems like it might be worth discussing 
the issues.

Or in short, "Security doesn't have to be perfect to be useful".

So, does Juha's approach offer any security benefits over simpler hacks, 
like my source-to-authority matching requirement? If it does, then let's 
understand those properties and see if any sort of standardization is 
needed. If not, then let's see what properties really are useful, and 
see if we need to document practices that exploit those properties for 
the operator community.

>for the most part this state is being kept where state belongs - in the UAs,
Absolutely true, and again a very strong argument.

>strength of the solution shows, I think, the versatility of this approach.
All true. But as Juha said, this approach requires gettting a valid, 
signed, checkable cert, which is non-trivial. I've been running my own 
fake CA for years, and I don't have any "real" certs to use. Do you?

--
Dean