Subject: [AAA-WG]: Issue 303: Security model for peer discovery and redirect - Text - Please Review

From: <[email-masked]>
Date: Thu, 28 Mar 2002 14:41:08 +0200

Hi all,

I've attempted to write some text for security concerns when using peer-to-peer connections.  Unfortunately (or is it fortunately) I missed out on the security 'pixie-dust' that was being handed out in Minneapolis, so I'm not sure if the text does the trick.  

At this point, I don't think we can do much better than providing guidence, so please verify that my guidence is completely out-to-lunch.

thanks,
John

13.3 Peer-to-Peer Considerations

There are many security issues related to peer-to-peer connections.  Caution should be used when creating peer-to-peer connections.  Diameter is not intended to allow the peer-to-peer interface to be a public interface.  The following is intended to provide some guidance on the issue.

A Diameter node SHOULD implement the same security mechanism (IPsec or TLS) across all its peer-to-peer connections.  Inconsistent use of security mechanisms can open security holes at a node.  For example if a node using both TLS and IPsec, there is not good way in which a connection that is not TLS-secured is, in fact, IPsec secured.  Additionally, a per-peer policy would need to be installed, which, in practice is quite hard to maintain.

If IPsec is used to secure the peer-to-peer connections to a Diameter node, then there SHOULD be a mechanism to prevent non-IPsec protected traffic from reaching the node.  For example, a firewall or inbound filter policy.

If IPsec is used and preconfigured SAs are not used, it is not recommended to rely on a PKI-based solution.  It is recommended that only peer-to-peer connections are created within a domain, or the Diameter nodes of an organization you trust.  

If TLS is used to secure peer-to-peer connections, it is recommended that certificates are used in such a way that you only allow peer-to-peer connections within a domain, or with the Diameter nodes of an organization you trust.

---

From: Bernard Aboba <[email-masked]>
Date: Fri, 29 Mar 2002 06:17:10 -0800 (PST)

> There are many security issues related to peer-to-peer connections.  Caution should be used when 
>creating peer-to-peer connections.  Diameter is not intended to allow the
>peer-to-peer interface to be a public interface.  

I'd change this to the following:

"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.
> 
> A Diameter node SHOULD implement the same security mechanism (IPsec or TLS) across 
> all its peer-to-peer connections.  Inconsistent use of security
> mechanisms can open security holes at a node.  For example if a node
> using both TLS and IPsec, there is not good way in which a connection
>that is not TLS-secured is, in fact, IPsec secured.  Additionally, a
> per-peer policy would need to be installed, which, in practice is quite
>hard to maintain.

Suggested change:

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 plumbed
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 the peer-to-peer connections to a Diameter node, 
>then there SHOULD be a mechanism to prevent non-IPsec protected traffic
>from reaching the node.  For example, a firewall or inbound filter
>policy.

Change to:

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. 

> 
> If IPsec is used and preconfigured SAs are not used, it is not recommended to 
> rely on a PKI-based solution.  It is recommended that only peer-to-peer
> connections are created within a domain, or the Diameter nodes of an
> organization you trust.

By preconfigured SAs, do you mean manual SAs? Not sure what we are saying
here; are we recommending against certificate-based authentication with
IPsec? My recommendation is to delete the above paragraph. 

> 
> If TLS is used to secure peer-to-peer connections, it is recommended that 
<certificates are used in such a way that you only allow peer-to-peer
>connections within a domain, or with the Diameter nodes of an
>organization you trust.  

I think this is covered by the above text.