[VOIPSEC] IPSec and VoIP Security

[Geoff Devine]

The original question from John DePietro was:
> We are looking for more optimized
> alternative to AKA, since AKA procedures require 4 SIP messages
> (Register/401/Register/200) plus 4 DIAMETER messages (MAR/MAA/SAR/SAA)
to
> establish SA parameters required for IPsec ESP with authentication and
> confidentiality.

The problem is typically the "initialization storm" that happens after
some kind of large failure.  It may "only" be four SIP messages and four
XML/Diameter/SCTP messages but it becomes a pretty big deal when you
have a million clients.  Parsing text-based SIP and XML messages isn't
exactly a computer-friendly operation and your network is out of service
unable to place and accept phone calls until this "initialization storm"
subsides.  In a primary line/lifeline environment, you could kill
somebody if you engineer this incorrectly.  One wrong entry in a routing
table or a backhoe destroying a fiber wiring conduit that's "supposed"
to be redundant can take out a network for hours and induce this
condition.

PacketCable 1.5 has a security solution based on Kerberos that scales
somewhat better than the 3GPP/IMS approach.  I've supplied a link to the
PacketCable 1.5 Security Specification.  Figure 10 on page 123 is the
boot sequence for a PacketCable client.  The last 10 steps in the table
labeled SEC-1 through SEC-10 are the message sequence needed to
authenticate with the soft switch.  The only message the soft switch
sees from the client is a Kerberos AP_REQUEST which is a TLV-based
protocol rather than a machine-unfriendly text based protocol.  Clients
interact directly with the Kerberos Key Distribution Center to get the
public keying information needed to talk to the soft switch and the KDC
can be horizontally scaled.

http://www.packetcable.com/downloads/specs/PKT-SP-SEC1.5-I01-050128.pdf

I'm not sure how this helps in a 3GPP/IMS environment where provisioning
data is distributed out to the HSS (thus the XML/Diameter/SCTP exchange)
and where the architecture uses the SIP 401 challenge mechanism which
doubles the SIP message count.  It would be a big change to rework the
SIP Registration method to optimize this.

Geoff Devine
Chief Architect
Cedar Point Communications

----------------------------------------------------------------------

From: "Yaron Sheffer" <yaronf at checkpoint.com>
Subject: Re: [VOIPSEC] IPSec and VoIP Security
To: "'DePietro, John'" <jdepietro at starentnetworks.com>,	"'Jon-Olov
	Vatn'" <vatn at kth.se>,	"'Alexandre Passito'"
	<alexandre.passito at gmail.com>
Cc: 'Joachim Orrblad' <joachim at orrblad.se>, Voipsec at voipsa.org
Message-ID: <000801c66cef$31cdeb00$132e1dc2 at ad.checkpoint.com>
Content-Type: text/plain;	charset="Windows-1252"

Hi John,

Why do you consider these 4 SIP messages to be an issue? After all, this
is
at registration time (i.e. when you turn the phone on), not at call
setup.

Thanks,
	Yaron

> -----Original Message-----
> From: DePietro, John [mailto:jdepietro at starentnetworks.com]
> Sent: Tuesday, April 25, 2006 16:54
> To: Jon-Olov Vatn; Alexandre Passito
> Cc: Joachim Orrblad; Voipsec at voipsa.org
> Subject: Re: [VOIPSEC] IPSec and VoIP Security
> 
> Hi,
> 
> Correct, IPsec terminates at the first SIP Proxy (Proxy-CSCF) as
defined
> in TS 23.228 and TS 23.203.
> 
> I will review the proposals below.  We are looking for more optimized
> alternative to AKA, since AKA procedures require 4 SIP messages
> (Register/401/Register/200) plus 4 DIAMETER messages (MAR/MAA/SAR/SAA)
to
> establish SA parameters required for IPsec ESP with authentication and
> confidentiality.
> 
> Regards,
> 
> John
> 
> -----Original Message-----
> From: Jon-Olov Vatn [mailto:vatn at kth.se]
> Sent: Tuesday, April 25, 2006 2:48 AM
> To: DePietro, John; Alexandre Passito
> Cc: Voipsec at voipsa.org; Joachim Orrblad
> Subject: Re: [VOIPSEC] IPSec and VoIP Security
> 
> 
> Hi,
> 
> IMS is not designed to use IPSec end-to-end as far as I understand,
> but it would be interesting to see if those methods could be used
> end-to-end too.
> 
> As an alternative I suggest that you have a look at Joachim Orrblad's
> master thesis "Alternatives to MIKEY/SRTP to secure VoIP" where he
> uses MIKEY to establish the IPSec-ESP security association, and
> also implements experimental support for it in Minisip, see
> http://www.minisip.org/publications.html
> Still, one should note that Orrblad prefers "SRTP" over "IPSec-ESP"
> to protect VoIP calls (see he conclusions).
> You may also find some more measurements on call setup delays
> for MIKEY with both SRTP and IPSec-ESP in Bilien et al
> "Secure VoIP: call establishment and media protection" found
> on the same page.
> 
> BW J-O
> 
> 
> DePietro, John wrote:
> 
> >Hi Passito,
> >
> >I suggest you look at the SIP AKA model for IPSEC, based on HTTP AKA.
> This is utilized in IMS (3GPP IMS, 3GPP2 MMD).  This may give you some
> idea to address your second issue "(key sharing, user permissions and
> etc)".
> >
> >-----Original Message-----
> >From: Voipsec-bounces at voipsa.org
[mailto:Voipsec-bounces at voipsa.org]On
> >Behalf Of Alexandre Passito
> >Sent: Tuesday, April 04, 2006 4:50 PM
> >To: Voipsec at voipsa.org
> >Subject: [VOIPSEC] IPSec and VoIP Security
> >
> >
> >Hi ALL,
> >
> >I'd like to start a discussion about using IPSec for end-to-end
security
> in
> >VoIP Systems. I have read some papers about the subject and it seens
that
> >IPSec is not completely suitable for this kind of task due to two
> reasons:
> >damage to some QoS metrics and the problem with management (key
sharing,
> >user permissions and etc). I'd like to hear some ideas about it,
future
> >trends and if there are well deployed solutions being tested.
> >
> >Best regards,
> >
> >Passito
> >
> >--
> >--
> >Alexandre Passito - Estudante de Mestrado
> >Universidade Federal do Amazonas (UFAM)
> >Departamento de Ci?ncia da Computa??o (DCC)
> >--
> >Alexandre Passito - M.Sc. Student
> >Federal University of Amazonas (UFAM)
> >Computer Science Department (DCC)
> >--
> >E-mail: passito at dcc.ufam.edu.br
> >Web: www.dcc.ufam.edu.br/~passito
> >Manaus - AM - Brasil
> >_______________________________________________
> >Voipsec mailing list
> >Voipsec at voipsa.org
> >http://voipsa.org/mailman/listinfo/voipsec_voipsa.org
> >
> >
> >"This email message and any attachments are confidential information
of
> Starent Networks, Corp. The information transmitted may not be used to
> create or change any contractual obligations of Starent Networks,
Corp.
> Any review, retransmission, dissemination or other use of, or taking
of
> any action in reliance upon this e-mail and its attachments by persons
or
> entities other than the intended recipient is prohibited. If you are
not
> the intended recipient, please notify the sender immediately -- by
> replying to this message or by sending an email to
> postmaster at starentnetworks.com -- and destroy all copies of this
message
> and any attachments without reading or disclosing their contents.
Thank
> you."
> >
> >_______________________________________________
> >Voipsec mailing list
> >Voipsec at voipsa.org
> >http://voipsa.org/mailman/listinfo/voipsec_voipsa.org
> >
> >
> 
> 





------------------------------

_______________________________________________
Voipsec mailing list
Voipsec at voipsa.org
http://voipsa.org/mailman/listinfo/voipsec_voipsa.org


End of Voipsec Digest, Vol 17, Issue 1
**************************************