Subject: [Sip] TLS vs IPsec

From: Rohan Mahy <[email-masked]>
Date: Tue, 29 Jan 2002 17:50:04 -0800 (Pacific Standard Time)

Hi Folks,

Some additional comments for the lively TLS vs IPsec debate.

Currently in bis-06 IPsec is a MAY, and TLS is a RECOMMENDED.  Since
neither of these are a MUST or even a SHOULD, implementations which want
security should be free to pick an appropriate mechanism.

World A:
I envision that realistically TLS will be used by computing devices that
have a general purpose web browser and a general purpose UI.  These
devices already need TLS and the associated PKI certificate code for web
commerce, and have enough memory and ergs to do this.  Because Proxys MUST
implement TLS, these devices can talk to ANY proxy.

World B:
Some embedded SIP UAs (ex: mobile phones, cable modems with embedded
gateways) will have a completely legitimate desire to use IPsec.
Many of these devices will use IPv6 which requires IPsec anyway.  There is
also a good chance that these boxes already have something like a SIM card
which contains a shared-secret key.  These boxes are probably running
IPv6 because there are supposed to be LOTS of them--therefore their
manufacturer probably wants them to be cheap.  This probably means they
have very little RAM.  They may also be using a scarce or specialized
Layer2 resource, so bandwidth and/or latency on this interface is an
issue.  Therefore using UDP when the messages are small (they are
incented to keep them small remember) is desirable.  If these devices are
using IPv6, it is unlikely that there will be a NAT between the UA and its
first-hop proxy.  By way of their SIM card, these devices are probably
pre-configured to use a specific set of first-hop proxies that are known
to support IPsec.

Interoperability between Worlds:
Now, for interoperability purposes, lets say that both Alice and Bob
implemented TLS on their UAs.  If Alice attempts to open a TLS connection
directly with Bob, their is a good chance that neither Alice nor Bob have
a "real" certificate.  If they both have self-signed certificates, Bob
would hopefully reject Alice's INVITE, possibly with a 305 Use Proxy
response.  If Alice goes through Bob's proxy, everything should work fine.
If Alice wants to communicate with Cathy (who only implemented IPsec), she
also has to go through Cathy's proxy, but everything still interoperates
fine, because Cathy's proxy supports TLS (with Alice), and IPsec (with
Cathy).

I think Jon is an advocate for "World A" and Mike an advocate for "World
B".  Realistically both these worlds will exist, and should interoperate.
We cannot and should not force fit one world into another (I'm not
accusing anyone here :-).

So what should we do?  I personally think the text in bis-06 is pretty
reasonable.  I think we can accomodate both worlds with very minor changes
in normative language.  The one thing we do need IMO is an IPsec profile
for SIP included as a peer to the TLS behavior.

I'd like to encourage the IPsec proponents like Jari and Mike to whack on
the IPsec profile this week (I know that Mike has already started on
this).

So.. if I had to fudge something now what would be my proposed new
recommendations?  Probably something like this...

SIP User Agents SHOULD implement a standard message integrity mechanism
(either TLS or IPsec as described later in this document).

It is RECOMMENDED that SIP User Agents implement a standard message
encryption mechanism (either TLS or IPsec as described later in this
document).

SIP User Agents which are designed for general purpose use on the
Internet at large SHOULD use TLS.  SIP User Agents designed for use in
private networks MAY use either TLS or IPsec.  SIP Proxy Servers used in
private networks MUST support TLS *and* whatever the User Agents use.

I also think we need a strong set of recommendations for SIP devices
implementing IPsec to parallel the TLS recommendations.  For example....

SIP User Agents which implement IPsec MUST support at least ESP
authentication with <foo> for message integrity, and SHOULD support at
least ESP with <bar> for confidentiality.  UAs MUST? support transport
mode and MAY? support tunnel mode.  UAs MAY use any keying mechanism, for
example shared-keys or IKE.  UAs MAY use self-signed certs or
purpose-built keys for client authentication.

SIP Proxies which implement IPsec MUST support both transport and tunnel
mode ESP with x, y, and z.  Proxies MUST implement IKE but MAY use
shared-keys or other keying mechanisms....

I hope this is useful.

thanks,
-rohan

_______________________________________________
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: Henning Schulzrinne <[email-masked]>
Date: Tue, 29 Jan 2002 21:25:29 -0500

> security should be free to pick an appropriate mechanism.

Not quite. According to RFC 2119, RECOMMENDED is the same strength as
SHOULD.

"3. SHOULD   This word, or the adjective "RECOMMENDED", mean that there
   may exist valid reasons in particular circumstances to ignore a
   particular item, but the full implications must be understood and
   carefully weighed before choosing a different course."