Subject: [Sip-security] A minimalist security framework for SIP

From: "Henning G. Schulzrinne" <[email-masked]>
Date: Sun, 18 Nov 2001 20:34:35 -0500

Instigated by some recent frustration expressed by a colleague, I
drafted a strawman that tries to get from the perennial (or, rather,
every-four-months) hand-wringing about the lack of progress on SIP
security to at least a summary of where we are and where we might be
able to get to reasonably quickly.

http://www.cs.columbia.edu/~hgs/sip/drafts/draft-schulzrinne-sip-security-00.txt

It's biased, rough and incomplete, but it's hopefully at least something
that can serve as a target for stones thrown. (I missed the 00 I-D
deadline, so don't expect to see this in the repository.)

I don't claim that this is the only viable model. Indeed, I think the
most important item right now is to avoid the entertaining but largely
pointless discussions as to which security mechanism is better. It is
likely that we'll need all non-broken mechanisms. Barring some major
breakthroughs in cryptography, it is also likely that we can't have all
four of the below:

- no centralized non-SIP infrastructure (KDCs)
- no public keys
- robust in the face of active man-in-the-middle attacks
- fast enough to run in 10 microseconds on a Z80

Thus, just setting up requirements that require security magic is also
not that helpful at this point.

If nothing else, I'm hoping that this will trigger somebody else to
write up an alternative, with different assumptions.

Henning
-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

_______________________________________________
Sip-security mailing list
[email-masked]
http://www1.ietf.org/mailman/listinfo/sip-security

---

From: "Jari Arkko" <[email-masked]>
Date: Mon, 19 Nov 2001 21:11:21 +0200

Nice draft. Here's a few comments:

>It is unlikely that a single mechanism will be able to solve
>all SIP security issues. It is thus pointless to argue whether

Yes! (And, that's exactly the kind of arguing that has taken
place on the list recently... my take on this is that we should
recognize where certain mechanisms and architectures are
usable and where they are not.)

>There is a strong preference for mechanisms that do not
>require an elaborate on-line infrastructure across the whole
>set of participants.

Indeed. I might add that it could be quite OK to have some
infrastructure such as a RADIUS/DIAMETER server on a
home org to keep the passwords/whatever for the users, but
if we start requiring some sort of global interconnection using
certificates between all users and all random proxies in the
network, we're in trouble.

>It may be possible to optimize performance by establishing a session
>key during the initial INVITE and then use HMAC or enhanced Digest
>authentication to protect the response and future exchanges between
>the two parties, either for the same session or for a session key
>lifetime spanning multiple sessions.

Yes, this is possible. (This is similar to what 3g folks want to do, though
they would typically set things up at registration time.)

>If the S/MIME operation is considered too heavy-weight AND if AMIM
>attack is discounted, ephemeral keys may be used instead. (If AMIM is
>possible, only public key cryptography, e.g., using S/MIME, or a
>Kerberos-like KDC model is known to work.)

I don't understand why you say AMIM protection implies 3rd parties
or PK cryptography. Can you explain?

The reason that HTTP authentication for instance is broken, is uh,
that it is broken and not because of any fundamental limitation.
Many (or maybe even most) SIP-based networks have "subscribers"
and "home networks" (companies or operators) that have a relationship
with the subscriber. In these cases it should be possible to arrange for
a shared secret, and to use that shared secret for the e2e (or at least
end-to-middle) protection of the signaling. 

e2e/e2m requires mainly an appropriate mechanism to agree
which parts of the message should be protected, not public keys.

By the way, I'm not certain if S/MIME can also do symmetric
schemes. Anyone?

>Barring some major

There are secure authentication methods based on symmetric schemes.
Coupled with a decent protection format (maybe like ESP but capable
of e2e as well), this would be quite fast. Maybe not 10 us on a Z80, but
a PK operation would not be needed. And active MITM attacks aren't
problem.

The need for pk or infrastructure seems to be more related to the kind
of trust model one has; secure communication to your home proxy/server
is quite OK even over other proxies, but if you want e2e to another random
user, or want security to a random proxy you go through, then there's
more trouble.

>In that case, it may be desirable to transfer a shared session secret
>to the other party and use it to sign the content using HMAC [7]. The
>signature protects the method, request-URI, body and a selected set
>of headers indicated in the header attribute.  [THIS NEEDS WORK.]

Again, this is something that I would find useful (and would be willing
to work on it if there's interest). BTW, running HTTP EAP + an EAP
method that can generate session keys +  Sanjoy et al draft
achieves something like this.

>The To, From, Call-ID, CSeq and Date header fields MUST be included
>in the HMAC.

Why not all? Or some set definition as in the Undery draft?

>In some cases, the inability to drop packets may allow the
...
>Need header signing (enhanced digest authentication), as described in
...

There are a few incomplete sentences around the draft.

Jari

---

From: "Henning G. Schulzrinne" <[email-masked]>
Date: Mon, 19 Nov 2001 15:03:55 -0500

Jari Arkko wrote:

> usable and where they are not.)

Yes, a more objective "applicability statement" for each would be
helpful.

> network, we're in trouble.

There's also a difference between having an on-line server
infrastructure and off-line certificates for servers. We have existence
proof that the latter works reasonably well, but various efforts at
on-line certificates or universal login seem to have up-time and
security difficulties even if run by a single large companies, as
opposed to the more likely loose affiliation of competitors.

> they would typically set things up at registration time.)

This seems to be somewhat different, namely setting up a session key
between the registrar and the user, rather than the two users (that are
likely to be on two different registrars). How does having a session key
help with the e2e issue?

> or PK cryptography. Can you explain?

Sorry, should've added that shared secret are also possible as a third
option. Does that make more sense?

> that it is broken and not because of any fundamental limitation.

Which brokenness are you referring to?

> end-to-middle) protection of the signaling.

I have a hard time with the e2e version. How does my local Verizon
shared secret help me when calling an AT&T customer, unless there's
something like a cross-certification of the KDCs involved?

> There are secure authentication methods based on symmetric schemes.

Again, I omitted those by accident, probably because N^2 shared secrets
between end users didn't seem that attractive.

> a PK operation would not be needed. And active MITM attacks aren't

The primary problem is getting shared secrets between two parties in
networks operated by competitors or in networks that don't know about
each other. Columbia University shouldn't have to set up a trust
relationship with kolumbus.fi for me to make a call to you.

> user, or want security to a random proxy you go through, then there's

I think we're in agreement. That's primarily my concern, as yours and
other work seem to provide a decent handle on the e2p case. In those
cases, shared secrets work quite well, as we know from login, network
file systems, etc.

> achieves something like this.

Indeed, I think it's a nice coincidence that all these drafts are
appearing. Maybe we can hash something out in SLC.

> Why not all? Or some set definition as in the Undery draft?

This is the minimal set. Others might be considered less important or
might change in transit. (Although so far, it seems that only the Via
header has the latter property.)

> There are a few incomplete sentences around the draft.

Yes, this was a Sunday afternoon effort. Thanks for reading it.
-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

---

From: "Jari Arkko" <[email-masked]>
Date: Mon, 19 Nov 2001 22:42:21 +0200

> likely to be on two different registrars). How does having a session key

These are definately different use cases, but it might be that the
SIP-level mechanisms to achieve the same thing could be similar.
Session keys are essentially an optimization, and they require some
form of symmetric crypto encapsulation (maybe CMS/digest/smime).
If we could assume that whatever authentication we do with our friends
and operators both can produce session keys, then both could use
similar methods to pass protected data in subsequent messages
without the overhead of new public key operations, AAA calls or
whatever that is needed.

> option. Does that make more sense?

Yes.

> Which brokenness are you referring to?

My main issue with it is that the auth-int doesn't cover enough.

> something like a cross-certification of the KDCs involved?

You're right, it doesn't help for the e2e case... at least not with INVITEs. Maybe it
does help in some of the other messages, such as REGISTER that are
e2e between you and your provider.

> between end users didn't seem that attractive.

Right. This boils down to the trust model that one wants to employ,
the original reason for doing security. Security for user x user is
definately hard without public keys or similar methods. Security
to your company/provider works better (perhaps even where that
company/provider acts as a proxy to give the second secure
m2e leg to the peer user).

> relationship with kolumbus.fi for me to make a call to you.

Yes. These could be different things, however. It could be that Columbia
University wants to protect your signaling as it passses through their
proxy, for accounting and other reasons, but they might not care at
all who you are talking to. If I wanted a secure session with you,
I propably wouldn't involve either organization in the trust model and
would exchange keys with you directly. Nevertheless, I'm quite willing
to go through a number of providers who perhaps require me to protect
my signaling as I pass through their proxies.

> cases, shared secrets work quite well, as we know from login, network

Yes. And I think we need the applicability statement also for the
shared secret model.

Jari

---

From: "Henning G. Schulzrinne" <[email-masked]>
Date: Sat, 24 Nov 2001 16:53:40 -0500

Jari Arkko wrote:

> network, we're in trouble.

As useful as they are, servers in the home domain are likely to only be
useful for REGISTER or INVITEs within the same domain.

> user, or want security to a random proxy you go through, then there's

That's what I'm focusing on, as we seem to have at least plausible
non-PK solutions for authenticating to a home proxy, say.

> Why not all? Or some set definition as in the Undery draft?

This already has a set definition (header=). The set I listed would seem
to be the minimal useful set for SIP; I clarified the wording.

Thanks again for the comments; I've folded them into the draft.
-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

---

From: "Henning G. Schulzrinne" <[email-masked]>
Date: Sat, 24 Nov 2001 17:17:55 -0500

> form of symmetric crypto encapsulation (maybe CMS/digest/smime).

Maybe we can separate the security processes into two parts:

(1) Obtain a shared secret

(2) Use it.

(1) can be via an earlier SMIME exchange between the two parties, via a
pre-shared key in a registration relationship, via some kind of
Kerberos-style KDC.

(2) would be either in Digest (requiring either a 401 round trip or the
MD5-sess mechanism in 2617), some form of HMAC or SMIME with shared
secrets (if that's possible).

Is that a 

> My main issue with it is that the auth-int doesn't cover enough.

The enhanced versions (Undery, Sen) address this, right?

> e2e between you and your provider.

For proxying the REGISTER to my home registrar, I don't see much need
for authentication at intermediate proxies (or for intermediate proxies
to authenticate themselves to me). What matters is that I'm talking to
the right registrar, and the registrar to the right user.

> m2e leg to the peer user).

Maybe we should discuss what "typical" deployments might look like. For
non-forwarded calls, it seems that

caller - [outbound proxy] - some number of other proxies -
["destination" proxy] - more proxies on the way to callee - callee

would be typical, where I enclosed the proxies doing authentication in
[]. If we can reduce this to

caller - [outbound proxy] - [destination proxy] - trusted network -
callee

things become somewhat simpler, as you could then indeed have "big
company" to "big company" authorization, somewhat similar to the trust
model in today's phone network. In that simplified model, as long as
both []'s have public keys (likely) and each party trusts each home
network operator, if the []'s use L3 or L4 security, users are
reasonably well protected. This obviously doesn't work if the
destination proxy (home network) ends up sending the request through
some untrusted network to the callee.

> my signaling as I pass through their proxies.

Protecting signaling seems like something we have L3 and L4 security
for.

---

From: Charles Kalmanek <[email-masked]>
Date: Sat, 24 Nov 2001 20:31:21 -0500

Hi, Henning,

Thanks for starting this discussion.  First, I'll list the
things which, at first reading, I like:

1. I agree that sip proxies should use pairwise network or 
   transport layer security associations to provide message 
   privacy and integrity.
2. Seems reasonable to assume that an important deployment 
   scenario will involve bilateral trust among companies 
   operating proxies.
3. I agree that we shouldn't assume that clients have 
   certificates.  (I need to think more about proxies).
4. Having outbound proxies sign all unsigned requests & 
   responses allows message authentication of the form "this 
   message originated by user@domain" for an authenticated 
   user.
5. Having clients HMAC messages once they have a shared key 
   allows end to end message privacy and integrity.

I'm not sure about enhanced digest though.  We've been 
thinking in what contexts it would be acceptable.  If
I understand it correctly, it does not provide either
privacy or proxy authentication.

Re: privacy.  Most people have come to expect that phone
calls are not trivially easy to eavesdrop on.  Without
secure signaling and secure media, this isn't true.  But
let's set this aside, since securing the media may be
perceived to be a somewhat high bar to set for a minimalist
solution.

Re: lack of proxy authentication.  At a minimum, I think
the draft should state the assumptions under which this 
provides acceptable security.  Pre-configured proxy address
in clients?  Only for use behind firewalls?  Spoofing a 
proxy is pretty easy on a LAN.  

chuck

---

From: Henning Schulzrinne <[email-masked]>
Date: Sat, 24 Nov 2001 22:02:43 -0500

> privacy or proxy authentication.

Correct, in its current form. I believe, however, that the Undery draft
can be trivially extended to work for Proxy-Authorization as well.
Digest 

> calls are not trivially easy to eavesdrop on.  Without

This may be a case of blissful ignorance: All it takes in my town is to
open the box on the main road and get a butt set and you'll get your
choice of the town's gossip. (The pedestal seems to be unlocked,
sometimes even with the door ajar.)

That said, I agree that we clearly need encryption in addition to
authentication. The S/MIME solution sketched (described would be too
generous a word) offers that. Would you suggest a different solution?

Another possibility is to rely on hop-by-hop encryption at L3 or L4.
Avoids exposing the "outer" headers, but has its own set of problems. I
vaguely remember somebody (your group?) proposing a Proxy-Require that
asks the next hop to use L3/4 encryption. Clearly, this has roughly the
same trust model as the currrent phone system.

> perceived to be a somewhat high bar to set for a minimalist

SRTP seems to be an ok solution for securing media, but the key exchange
problem remains. S/MIME encryption of SDP is one solution; some version
of Kerberos KDCs have been suggested here recently. Other approaches?

> proxy is pretty easy on a LAN.

You mean the client ascertaining the identity of the server or the other
way around?

---

From: "Jari Arkko" <[email-masked]>
Date: Sun, 25 Nov 2001 09:17:33 +0200

> proxy is pretty easy on a LAN.

The current Digest proxy mechanisms are pretty useless,
imho. It only works one way, it doesn't protect all of the messages
even where it could, it is hard to protect responses, etc. So
we need some work here. My personal view of what should
get is a two-level solution where the first level is mandatory
and the second one is optional for those who have the CPU.
The first level should provide at least integrity and replay
protection, and operate based on symmetric crypto (e.g.
enhanced digest). The second level should provide in
addition operation in a N x N networks using asymmetric
crypto, and confidentiality (e.g. S/MIME). You could perhaps
compare these levels to having manually keyed IPsec, and
IPsec with certs. (Of course, IPsec wouldn't cut it because we
need to go through proxies.)

Question: does anyone know if S/MIME gives replay
protection? Does everyone agree that we need replay
protection? I would assume so, unless we want to allow
attackers to replay a dangerous or expensive INVITE.

As for making Digest better, the following may help (though I
think it should be extended to cover end-to-end as well, and
perhaps merged with the undery work):

http://search.ietf.org/internet-drafts/draft-sen-sipping-onehop-digest-00.txt

Jari

---

From: "Jari Arkko" <[email-masked]>
Date: Sun, 25 Nov 2001 09:01:24 +0200

> > But let's set this aside, since securing the media may be

I think we should allow for secure media as well, though propably not all
hosts want do that so it should be an optional component of the framework.
As for the key management of SRTP, here's another approach:

http://search.ietf.org/internet-drafts/draft-ietf-msec-mikey-00.txt

Jari

---

From: "Henning G. Schulzrinne" <[email-masked]>
Date: Sun, 25 Nov 2001 10:59:58 -0500

This would seem largely orthogonal to SIP security, even though SIP (and
SDP) may be participants.

---

From: Charles Kalmanek <[email-masked]>
Date: Sun, 25 Nov 2001 11:13:59 -0500

Hi, Henning.  Comments inline.

> can be trivially extended to work for Proxy-Authorization as well.

I'd say that this is worth doing.  Is the same extension feasible
for digest+pnonce?  

> sometimes even with the door ajar.)

Understood, but with many Ethernet installations, it's the equivalent
of bringing the "box" into my office, where I can sniff packets w/
impunity.  In corporate LANs for example, I think managers would
be legimately concerned to learn that employees could trivially 
eavesdrop on their phone calls.

> generous a word) offers that. Would you suggest a different solution?

I need to read through all the S/MIME stuff; will get back to
you.

> of Kerberos KDCs have been suggested here recently. Other approaches?

Well, proxies might be another example of a trusted 3rd party.
But I haven't thought through the trust models enough to advocate
this approach.

> You mean the client ascertaining the identity of the server or the other

I was alluding to the ability of a random host on a LAN to 
respond to or generate messages as if they were the local proxy.

---

From: "Henning G. Schulzrinne" <[email-masked]>
Date: Sun, 25 Nov 2001 11:31:29 -0500

> I'd say that this is worth doing.  Is the same extension feasible

I believe so. James willing, I will be working with him to make this
happen.

> eavesdrop on their phone calls.

Well, they'd be surprised to learn that in some cases, employees can
trivially eavesdrop on their email...

However, issues of perception vs. reality aside, we clearly need to have
good solution for media privacy.

One question that isn't clear to me is whether there are cases where
SRTP is needed and IPsec wouldn't work. I'm trying to minimize the
number of security protocols, particularly special-purpose ones. I can
see that RTP translators would mess up IPsec. Anything else?

> respond to or generate messages as if they were the local proxy.

I agree that that is bad, but wouldn't IPsec or TLS be the appropriate
solution here, given that the outbound proxy is one IP hop away from the
client?

---

From: "Jari Arkko" <[email-masked]>
Date: Sun, 25 Nov 2001 18:54:01 +0200

> SDP) may be participants.

Yes, and I think we like it orthogonal. Then we can concentrate on SIP security
on ensuring that the signaling is protected.

Jari

---

From: "Jari Arkko" <[email-masked]>
Date: Sun, 25 Nov 2001 18:53:01 +0200

> see that RTP translators would mess up IPsec. Anything else?

Headers on a low bandwidth link. More seriously, ESP CBC cipher
behaviour with respect to bit errors. SRTP survives bit errors, in ESP
they in practise destroy the whole packet.

Jari

---

From: Charles Kalmanek <[email-masked]>
Date: Sun, 25 Nov 2001 22:35:32 -0500

Comments inline.

> good solution for media privacy.

Agreed.

> see that RTP translators would mess up IPsec. Anything else?

When RTP translators are present, it seems that they are an endpoint
either of the IPsec SA or the SRTP session.  Is there a major 
difference?

> solution here, given that the outbound proxy is one IP hop away from the

Exactly.  We have been trying to determine under what scenarios
digest+enhancements might be acceptable.  I'm not sure there are
many.

---

From: Henning Schulzrinne <[email-masked]>
Date: Sun, 25 Nov 2001 23:12:08 -0500

> either of the IPsec SA or the SRTP session.  Is there a major

Not that I can tell, but others have pointed out more important
differences.

> digest+enhancements might be acceptable.  I'm not sure there are

I think it remains a good low-cost solution for e2e authentication
(where IPsec and TLS wouldn't do), in particular REGISTER and SUBSCRIBE,
but also INVITE. IPsec and TLS have costs, as discussed earlier, both in
terms of implementation complexity and delay.