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

From: <[email-masked]>
Date: Mon, 1 Apr 2002 22:58:39 +0300

Hi Bernard,

The text you suggested covered everything I intended, an more fully as 
well.

I've added the text, so I consider 303 as CLOSED.

John

> -----Original Message-----
> From: ext Bernard Aboba [mailto:[email-masked]]
> Sent: 29 March, 2002 16:17
> To: Loughney John (NRC/Helsinki)
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: Re: [AAA-WG]: Issue 303: Security model for peer discovery
> andredirect - Text - Please Review
> 
> 
> > 
> > 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.  
> 
> 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.  
> 
>