Subject: [Ieprep] clarifications about security

From: "Krishnaswamy, Arvind Shankar (UMKC-Student)" <[email-masked]>
Date: Fri, 5 Apr 2002 11:27:18 -0600

I have 2 (trivial?) questions.

(1)
The most significant drawback to utilizing Public Key encryption is that
it is slow. Public Key encryption requires about a thousand times
greater CPU time to use than does a typical Symmetric Key technique
(using password). 
We may have to compromise on QoS because ESP(Encapsulating Security
Payload) encrypts the data sent too which is computationally
expensive(an IP telephony gateway relies on high-performance to maintain
its quality of service). Is this compromise something which we can
adjust to?

(2)
Proxy servers/Firewalls in IP telephony gateways can be used to maintain
Access control lists to include only friendly neighbors (e.g., other
gateways) so that DoS attacks can be prevented. By only recognizing
friendly machines, this technique of proxy servers or firewalls is one
of the most effective methods against outside intrusion on the physical
system and its resources. Can this be included as a security
requirement?

-Arvind

_______________________________________________
Ieprep mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ieprep

---

From: "Rosen, Brian" <[email-masked]>
Date: Fri, 5 Apr 2002 14:13:50 -0500

> its quality of service). Is this compromise something which we can
Hello?  ESP would use a symmetric key (relatively fast).  You
could use PK to authenticate, and then use DH to negotiate the
key you use for encryption.  So you get one authentication
and a DH PER CALL, and then use something like AES for data.

HOWEVER, we are mixing several pieces of the puzzle here. 
For SIP based voice/video, you might use ESP for the SIP signalling
channel, but you are probably better off using TLS.  For the
media channels, you are better off using SRTP, which encrypts the
RTP, rather than encrypting at a lower layer like ESP would.

The principles remain the same - PK for authentication, symmetric
for bulk data (media) encryption.

> system and its resources. Can this be included as a security
Yes, you will want to rely on decent authentication mechanisms to
prevent attacks.  SIP has such mechanisms, although there is need
for better ones.  The IEPS problem presents authentication challenges
such as definition of trust boundaries, cross realm authentication,
and providing secure authentication in an imperfect world.

For example - GETS cards are nice, but can't hold a lot of information;
all you get is PIN/Password authentication.  Smart cards are better, but you
can't assume a smartcard reader in every device you may wish to use.
We might be able to use them in VoIP phones you carry to an emergency,
but I doubt that is acceptable in the general case.  Tokens (SecureID)
would be great, but they are too big for a wallet.  There is this
new implantable ID mechanism ;)

Brian

---

From: "Rosen, Brian" <[email-masked]>
Date: Mon, 8 Apr 2002 09:39:00 -0400

SIP already has TLS support specified.  While I personally think
IPSEC is more appropriate in many circumstances, and you can 
always deploy it if you wish, it would be best I think to
stick with the TLS specs in the SIP specs.

Note that SIP signalling can traverse many hops, with the media
streams going directly end-to-end.  TLS/IPSEC has to be applied
on every hop to get security end to end.  There is a spec about
that, but you understand that it's easy to lie about such a
chain of trust associations.  There is an S/MIME based end-to-end
scheme when you really need some information held confidential
end-to-end.  As a practical matter, anything that is needed to
route a message has to be examined by intermediate entities (SIP
Proxy Servers) and thus usually cannot be encrypted by the S/MIME
mechanisms.  The hop-by-hop techniques using TLS (or IPSEC) do
work for that.  

The TLS mechanisms are mandatory-to-implement for proxy servers.
However, they may not be enabled at all the intermediaries you
may encounter in an emergency.  Carefull attention to what is
placed in which headers, and judicious use of the S/MIME mechanism
should allow a sufficiently robust confidentiality environment.

I agree than SRTP is what we want for the media streams.

Brian

> -----Original Message-----
> From: Ian Brown [mailto:[email-masked]]
> Sent: Monday, April 08, 2002 9:20 AM
> To: Alistair Munro
> Cc: ieprep
> Subject: RE: [Ieprep] clarifications about security
> 
> 
> > Do we require the handsets to support additional
> > protocols for security purposes? If so which ones?
> 
> Most likely IPSEC/TLS for signalling protection and SRTP for content
> protection.
> 
>

---

From: "Russert, Steven W" <[email-masked]>
Date: Mon, 8 Apr 2002 07:48:00 -0700

Brian,
	IPSEC has two modes - the "tunnel" mode secures traffic between two
network devices as you state below, but the "transport" mode sets up a
secure session between two endpoints.  Thus, the IPSEC session has only to
be set up once (in that mode).
Regards,
Steve Russert

-----Original Message-----
From: Rosen, Brian [mailto:[email-masked]]
Sent: Monday, April 08, 2002 6:39 AM
To: 'Ian Brown'; Alistair Munro
Cc: ieprep
Subject: RE: [Ieprep] clarifications about security

Brian

---

From: "Rosen, Brian" <[email-masked]>
Date: Mon, 8 Apr 2002 11:01:27 -0400

Yes, I know that, and either could be established without any 
SIP applications knowing it was there on a particular hop.
The problem is, in an emergency, how does a user know if his
SIP message sequence is private from end to end?  SIP messages
may traverse several proxy servers.  The first hop (from
the user's device to the first proxy) could be known to the user
in some circumstances, but in many emergency circumstances, you
can't assume that the network you are plugging into has
IPSEC available for an arbitrary device plugged in.  Even if you
could, the next hop may not be so protected, and you have no
way of knowing.  

Tunnelling through a network to get to a secure proxy server is possible, 
but in general, I think most scenarios have to assume that existing 
proxy servers will be needed to correctly route messages.  If that's 
not the case, then you could have a SIP device that had an IPSEC 
implementation, that tunneled through an unknown network, to get to 
a known (and secure) network.  In that instance, IPSEC is useful.
Of course, the TLS implementation that is provided for in the specs
would also work. 

Of course, many firewalls would stop you as presently configured.

Brian

> From: Russert, Steven W [mailto:[email-masked]]
> Sent: Monday, April 08, 2002 10:48 AM
> To: 'Rosen, Brian'
> Cc: ieprep