|
Written by Hemanshu Patel
|
|
Tuesday, 06 November 2007 |
|
Page 13 of 13
12. Diameter protocol related configurable parameters
This section contains the configurable parameters that are found
throughout this document:
Diameter Peer
A Diameter entity MAY communicate with peers that are statically
configured. A statically configured Diameter peer would require
that either the IP address or the fully qualified domain name
(FQDN) be supplied, which would then be used to resolve through
DNS.
Realm Routing Table
A Diameter proxy server routes messages based on the realm portion
of a Network Access Identifier (NAI). The server MUST have a
table of Realm Names, and the address of the peer to which the
message must be forwarded to. The routing table MAY also include
a "default route", which is typically used for all messages that
cannot be locally processed.
Tc timer
The Tc timer controls the frequency that transport connection
attempts are done to a peer with whom no active transport
connection exists. The recommended value is 30 seconds.
13. Security Considerations
The Diameter base protocol assumes that messages are secured by using
either IPSec or TLS. This security mechanism is acceptable in
environments where there is no untrusted third party agent. In other
situations, end-to-end security is needed.
Diameter clients, such as Network Access Servers (NASes) and Mobility
Agents MUST support IP Security [SECARCH] and MAY support TLS [TLS].
Diameter servers MUST support TLS and IPsec. Diameter
implementations MUST use transmission-level security of some kind
(IPsec or TLS) on each connection.
If a Diameter connection is not protected by IPsec, then the CER/CEA
exchange MUST include an Inband-Security-ID AVP with a value of TLS.
For TLS usage, a TLS handshake will begin when both ends are in the
open state, after completion of the CER/CEA exchange. If the TLS
handshake is successful, all further messages will be sent via TLS.
If the handshake fails, both ends move to the closed state.
It is suggested that IPsec be used primarily at the edges for intra-
domain exchanges. For NAS devices without certificate support, pre-
shared keys can be used between the NAS and a local AAA proxy.
For protection of inter-domain exchanges, TLS is recommended. See
Sections 13.1 and 13.2 for more details on IPsec and TLS usage.
13.1. IPsec Usage
All Diameter implementations MUST support IPsec ESP [IPsec] in
transport mode 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.
Diameter implementations MUST support IKE for peer authentication,
negotiation of security associations, and key management, using the
IPsec DOI [IPSECDOI]. Diameter 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
Diameter 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
Diameter 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.
13.2. TLS Usage
A Diameter node that initiates a connection to another Diameter node
acts as a TLS client according to [TLS], and a Diameter node that
accepts a connection acts as a TLS server. Diameter nodes
implementing TLS for security MUST mutually authenticate as part of
TLS session establishment. In order to ensure mutual authentication,
the Diameter node acting as TLS server must request a certificate
from the Diameter node acting as TLS client, and the Diameter node
acting as TLS client MUST be prepared to supply a certificate on
request.
Diameter nodes 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
Diameter nodes SHOULD be able to negotiate the following TLS cipher
suite:
TLS_RSA_WITH_AES_128_CBC_SHA
Diameter nodes MAY negotiate other TLS cipher suites.
13.3. Peer-to-Peer Considerations
As with any peer-to-peer protocol, proper configuration of the trust
model within a Diameter peer is essential to security. When
certificates are used, it is necessary to configure the root
certificate authorities trusted by the Diameter peer. These root CAs
are likely to be unique to Diameter 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 Diameter peer and other organizations. As a result, a
Diameter peer will typically not be configured to allow connectivity
with any arbitrary peer. When certificate authentication Diameter
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 Diameter 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 Diameter 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
Diameter, unique pre-shared keys are configured with Diameter 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
Diameter 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 Diameter 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
Diameter, a typical security policy for outbound traffic is "Initiate
IPsec, from me to any, destination port Diameter"; for inbound
traffic, the policy would be "Require IPsec, from any to me,
destination port Diameter".
This policy causes IPsec to be used whenever a Diameter peer
initiates a connection to another Diameter peer, and to be required
whenever an inbound Diameter 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 Diameter 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 Diameter 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 Diameter 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 Diameter connection. To avoid
this, it would be necessary to plumb peer-specific policies either
statically or dynamically.
If IPsec is used to secure Diameter 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.
|
|
| |
|
|
Diameter Protocol 
