Subject: RE: [Sigtran] FW: some comments on security for sigtran

From: [email-masked]
Date: Tue, 23 Jul 2002 16:17:30 +0300

Hi John,

can you provide the arguments or refer to another document which explain
following statement from your text: "When pre-shared keys are used for
authentication, IKE Aggressive Mode SHOULD be used, and IKE Main Mode
SHOULD NOT be used"?
Why not to work in Main mode with pre-shared keys?

Regards,
Lev.

                      john.loughney@no                                                                     
                      kia.com                  To:      <[email-masked]>, <[email-masked]>              
                      Sent by:                 cc:      <[email-masked]>                                  
                      sigtran-admin@ie         Subject: RE: [Sigtran] FW: some comments on security for    
                      tf.org                   sigtran                                                     

                      30/06/02 07:40                                                                       

Hi all,

I've tried to address some of thie issues found with SUA.  As I
understand, the IAB thinks this is an issue for all SIGTRAN protocols,
so I'd appreciate having some feedback on this.

I intend to still work on this a bit, then resubmit the text.  Some
of the text is cobbled together from text I have worked in in Diameter.
I still need to sort out the MUSTs, SHOULDs, etc.

The text comes after the IAB's concerns.

> > ------------------------------------------------------------------
> > Just so we're on the same page, I'll start with my one paragraph
> > summary of SIGTRAN. This shouldn't be news, but I want to have it on
> > the table lest it show that I'm confused :)
> >
> > SIGTRAN SUMMARY
> > The current telco infrastructure consists of a bunch of devices
> > connected via hardwired private links. The purpose of SIGTRAN
> > appears to be allow telco signalling (and sometimes data) to
> > run over the public Internet instead. This is done by specifying
> > bindings of those protocols to IP via adaptation layers, typically
> > running over SCTP. The typical architecture is to have a gateway
> > that speaks the PSTN protocol on one side and the SIGTRAN-hosted
> > protocol on the other, though one can of course have an endpoint
> > which just speaks the SIGTRAN hosted-protocols.
> >
> > SECURITY ISSUES
> > In my view, the high level security choice that needs to be made is
> > what kind of system SIGTRAN is to be. We know what kind of system the
> > PSTN is: peers are physically wired to other peers so each entity
> > basically trusts any other entity on the network. When we move to
> > the Internet, there are two basic approaches:
> >
> > (1) Emulate a private network. Just nail up IPsec/TLS links between
> > the peers to replace the physical links that used to exist. I'm
> > basically assuming that we'd just keep all the same security stuff (if
> > any) that the PSTN uses, since we're just replacing wires with VPN
> > links. The right model here is to think of VPN links as "virtual
> > wires", as Steve Bellovin says. This is by far the simplest security
> > approach since it doesn't require designing an entirely new security
> > model, just replacing one component.
> >
> > This appears to be the approachthat the protocol designers have in
> > mind. If this is what's done, then things are relatively simple, but
> > the documents need to specify how it's done. Two major choices need to
> > be made:
> >
> >    (a) What kind of keying to use.
> >        Since the links are essentially statically configured,
> >        preconfigured keys make the most sense. For IPsec, this
> >        probably means authenticating your DH exchange with a shared
> >        secret. For TLS it means statically configured self-signed
> >        certificates. (This approach could be used for IPsec as well.)
> >
> >    (b) IPsec vs. TLS.
> >        Since SIGTRAN is always going to run over SCTP, TLS seems like
> >        the better choice here, but it's really just a matter of
> >        convenience which one is chosen.
> >
> > In any case, the documents should specify both these choices as
> > well as mandatory to implement algorithms.
> >
> >
> > (2) Assume that it's a basically open system, in which case
> > we have to solve all sorts of difficult and serious security
> > problems of the kind that SIP is trying to confront now. In
> > particular:
> >
> >          (a) Authentication. In an open system you're pretty much
> >              going to need some sort of PKI to identify endpoints.
> >          (b) Authorization. Once we know who a peer is, how do we
> >              know whether he's entitled to handle a given class
> >              of traffic or not?
> >          (c) Transitive protection. Once we have the authorization
> >              problem dealt with on a hop-by-hop basis, we have
> >              to ask whether you trust your neighbor to correctly
> >              verify that the peer he's talking to is entitled to
> >              handle a given class of traffic. Probably not, so
> >              now you need some kind of message security system
> >              to allow nodes to authenticate nodes that they're not
> >              directly connected to.
> >
> > Judging from our experience with SIP, I'm naturally kind of wary
> > of strategy (2) but I fear that it's inevitable. If that's the
> > way that we're going it's going to need some heavy thinking. This
> > kind of secure multihop packet switching network is a security
> > problem that hasn't seen that much attention and doesn't really
> > have a standard solution.

6 Security Considerations

6.1 Introduction

SUA is designed to carry signaling messages for telephony services. In some
cases, SUA may be deployed on both an intra-domain (single service
provider) and an inter-domain (multiple service providers) basis.  The
security requirements for these situations may be different.

SUA involves the security needs of several parties: the end users of the
services; the network providers and the applications involved.  Additional
security requirements may come from local regulation.  While having some
overlapping security needs, any security solution should fulfill all of the
different parties' needs.

SUA assumes that messages are secured by using either IPSec or TLS.

6.2 Threats

There is no quick fix, one-size-fits-all solution for security.  As a
transport protocol, SUA has the following security objectives:

 * Availability of reliable and timely user data transport.
 * Integrity of user data transport.
 * Confidentiality of user data.

SUA runs on top of SCTP.  SCTP provides certain transport related security
features, such as:

 * Blind Denial of Service Attacks
 * Flooding
 * Masquerade
 * Improper Monopolization of Services

When SUA is running in professionally managed corporate or service provider
network, it is reasonable to expect that this network include an
appropriate security policy framework. The "Site Security Handbook" [2196]
should be consulted for guidance.

When the network in which SUA runs in involves more than one party, it may
not be reasonable to expect that all parties have implemented security in a
sufficient manner. End-to-end security should be the goal; therefore, it is
recommended that IPSEC be used to ensure confidentiality of user payload.
Consult [2409] for more information on configuring IPSEC services.

6.3 Protecting Confidentiality

Particularly for mobile users, the requirement for confidentiality may
include the masking of IP addresses and ports.  In this case application
level encryption is not sufficient; IPSEC ESP should be used instead.
Regardless of which level performs the encryption, the IPSEC ISAKMP service
should be used for key management.

6.4 IPsec Usage

All SUA implementations MUST support IPsec ESP [IPsec] in transport mode
with with non-null encryption and authentication algorithms to provide
per-packet authentication, integrity protection and confidentiality, and
MUST support the replay protection mechanisms of IPsec.

SUA implementations MUST support IKE for peer authentication, negotiation
of security associations, and key management, using the IPsec DOI
[IPSECDOI]. SUA implementations MUST support peer authentication using a
pre-shared key, and MAY support certificate-based peer authentication using
digital signatures. Peer authentication using the public key encryption
methods outlined in IKE's sections 5.2 and 5.3 [IKE] SHOULD NOT be used.

Conformant implementations MUST support both IKE Main Mode and Aggressive
Mode. When pre-shared keys are used for authentication, IKE Aggressive Mode
SHOULD be used, and IKE Main Mode SHOULD NOT be used. When digital
signatures are used for authentication, either IKE Main Mode or IKE
Aggressive Mode MAY be used.

When digital signatures are used to achieve authentication, an IKE
negotiator SHOULD use IKE Certificate Request Payload(s) to specify the
certificate authority (or authorities) that are trusted in accordance with
its local policy. IKE negotiators SHOULD use pertinent certificate
revocation checks before accepting a PKI certificate for use in IKE's
authentication procedures.

The Phase 2 Quick Mode exchanges used to negotiate protection for SUA
connections MUST explicitly carry the Identity Payload fields (IDci and
IDcr). The DOI provides for several types of identification data. However,
when used in conformant implementations, each ID Payload MUST carry a
single IP address and a single non-zero port number, and MUST NOT use the
IP Subnet or IP Address Range formats. This allows the Phase 2 security
association to correspond to specific TCP and SCTP connections.

Since IPsec acceleration hardware may only be able to handle a limited
number of active IKE Phase 2 SAs, Phase 2 delete messages may be sent for
idle SAs, as a means of keeping the number of active Phase 2 SAs to a
minimum. The receipt of an IKE Phase 2 delete message SHOULD NOT be
interpreted as a reason for tearing down a SUA connection. Rather, it is
preferable to leave the connection up, and if additional traffic is sent on
it, to bring up another IKE Phase 2 SA to protect it. This avoids the
potential for continually bringing connections up and down.

6.5  TLS Usage

A SUA peer that initiates a connection to another SUA peer acts as a TLS
client according to [TLS], and a SUA peer that accepts a connection acts as
a TLS server.  SUA peers implementing TLS for security MUST mutually
authenticate as part of TLS session establishment.  In order to ensure
mutual authentication, the SUA node acting as TLS server must request a
certificate from the SUA node acting as TLS client, and the SUA node acting
as TLS client MUST be prepared to supply a certificate on request.

SUA peers supporting TLS MUST be able to negotiate the following TLS cipher
suites:

TLS_RSA_WITH_RC4_128_MD5
TLS_RSA_WITH_RC4_128_SHA
TLS_RSA_WITH_3DES_EDE_CBC_SHA

SUA nodes MAY negotiate other TLS cipher suites.

6.6 Peer-to-Peer Considerations

As with any peer-to-peer protocol, proper configuration of the trust model
within a SUA peer is essential to security. When certificates are used, it
is necessary to configure the root certificate authorities trusted by the
SUA peer. These root CAs are likely to be unique to SUA usage and distinct
from the root CAs that might be trusted for other purposes such as Web
browsing. In general, it is expected that those root CAs will be configured
so as to reflect the business relationships between the organization
hosting the SUA peer and other organizations. As a result, a SUA peer will
typically not be configured to allow connectivity with any arbitrary peer.
When certificate authentication SUA peers may not be known beforehand, and
therefore peer discovery may be required.

Note that IPsec is considerably less flexible than TLS when it comes to
configuring root CAs. Since use of Port identifiers is prohibited within
IKE Phase 1, within IPsec it is not possible to uniquely configure trusted
root CAs for each application individually; the same policy must be used
for all applications. This implies, for example, that a root CA trusted for
use with SUA must also be trusted to protect SNMP. These restrictions can
be awkward at best. Since TLS supports application-level granularity in
certificate policy, TLS SHOULD be used to protect SUA connections between
administrative domains. IPsec is most appropriate for intra-domain usage
when pre-shared keys are used as a security mechanism.

When pre-shared key authentication is used with IPsec to protect SUA,
unique pre-shared keys are configured with SUA peers, who are identified by
their IP address (Main Mode), or possibly their FQDN (Aggressive Mode). As
a result, it is necessary for the set of SUA peers to be known beforehand.
Therefore, peer discovery is typically not necessary.

The following is intended to provide some guidance on the issue.

It is recommended that a SUA peer implement the same security mechanism
(IPsec or TLS) across all its peer-to-peer connections. Inconsistent use of
security mechanisms can result in redundant security mechanisms being used
(e.g. TLS over IPsec) or worse, potential security vulnerabilities. When
IPsec is used with SUA, a typical security policy for outbound traffic is
"Initiate IPsec, from me to any, destination port SUA"; for inbound
traffic, the policy would be "Require IPsec, from any to me, destination
port SUA".

This policy causes IPsec to be used whenever a SUA peer initiates a
connection to another SUA peer, and to be required whenever an inbound SUA
connection occurs. This policy is attractive, since it does not require
policy to be set for each peer or dynamically modified each time a new SUA
connection is created; an IPsec SA is automatically created based on a
simple static policy. Since IPsec extensions are typically not available to
the sockets API on most platforms, and IPsec policy functionality is
implementation dependent, use of a simple static policy is the often the
simplest route to IPsec-enabling a SUA implementation.

One implication of the recommended policy is that if a node is using both
TLS and IPsec, there is not a convenient way in which to use either TLS or
IPsec, but not both, without reserving an additional port for TLS usage.
Since SUA uses the same port for TLS and non-TLS usage, where the
recommended IPsec policy is put in place, a TLS-protected connection will
match the IPsec policy, and both IPsec and TLS will be used to protect the
SUA connection. To avoid this, it would be necessary to plumb peer-specific
policies either statically or dynamically.

If IPsec is used to secure SUA peer-to-peer connections, IPsec policy
SHOULD be set so as to require IPsec protection for inbound connections,
and to initiate IPsec protection for outbound connections. This can be
accomplished via use of inbound and outbound filter policy.

References

[IKE]                    D. Harkins, D. Carrel, "The Internet Key Exchange
(IKE)", RFC 2409, November 1998.

[IPSECDOI]         D. Piper, "The Internet IP Security Domain of
Interpretation for ISAKMP", RFC 2407, November 1998.

[TLS]                    T. Dierks, C. Allen, "The TLS Protocol Version
1.0", RFC 2246, January 1999.

[TLSSCTP]          M. Tuexen, et al. "TLS over SCTP" IETF Work in Progress.

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

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

---

From: [email-masked]
Date: Mon, 29 Jul 2002 17:52:47 +0300

Hi John,

Regards,
Lev.

                      john.loughney@no                                                                     

                      30/06/02 07:40                                                                       

Hi all,

6.1 Introduction

6.2 Threats

6.4 IPsec Usage

6.5  TLS Usage

TLS_RSA_WITH_RC4_128_MD5
TLS_RSA_WITH_RC4_128_SHA

References