Subject: [AAA-WG]: Resolution of Issue 321: Normative references to CMS

From: <[email-masked]>
Date: Mon, 13 May 2002 16:32:53 +0300

Hi all,

I have now made all of the modifications for issue 321.  The major text added
is as follows:

1.4 Terminology

Diameter Security Exchange

A Diameter Security Exchange is a process through which two Diameter nodes 
establish end-to-end security.
[editor's note: this is the term to be used for the DSAR/DSAA message exchange)

End-to-End Security

TLS and IPsec provide hop-by-hop security, or security across a transport 
connection. When relays or proxy are involved, this hop-by-hop security may 
not protect the entire Diameter user session.  End-to-end security is security 
across a Diameter session.  

Security Association

A security association is an association between two endpoints in a Diameter 
session which allows the endpoints to communicate with integrity and confidentially, 
even in the presense of relays and/or proxies.

=====================

2.9 End-to-End Security Framework

The basic components of end-to-end security include encryption and 
message origin authentication, or in otherwords, AVP integrity and 
confidentiality between two peers communicating through agents.
         
End-to-end security can be provided by an end-to-end security 
extension, which is not defined in the base protocol specification.  
There is ongoing work toward an end-to-end security session [CMS]
         
The circumstances requiring the use of end-to-end security are determined 
by service provider policy. This policy is not the subject of standardization. 
This policy may be indexed by next hop Diameter peer or by destination realm.  
For example, use of TLS or IPsec for Diameter peers communicating in on a 
peer-to-peer basis, without relays or proxies may be sufficient in many cases.

The use of end-to-end security can be classified as the following:
         
	- Never use end-to-end security.
            
	- Use end-to-end security on messages containing sensitive AVPs.  
  	  Which AVPs are sensitive is determined by service provider policy.  
	  AVPs containing keys and passwords should be considered sensitive.  
	  Accounting AVPs may be considered sensitive.  Any AVP for which the P bit 
	  may be set or which may be encrypted may be considered sensitive.
               
	- Always use end-to-end security.

It is strongly recommended that all Diameter implementations support end-to-end
security.

=====================

4.6  Diameter Base Protocol AVPs

The following table describes the Diameter AVPs defined in the base protocol, 
their AVP Code values, types, possible flag values and whether the AVP MAY be 
encrypted.  For the originator of a Diameter message, "MAY Encr" means that if 
a message containing that AVP is to be sent via a proxy/agent then the message 
MUST NOT be sent unless there is end-to-end security between the originator and 
the recipient OR the originator has locally trusted configuration that indicates 
that end-to-end security is not needed. Similarly, for the originator of a Diameter 
message, a "P" in the "MAY" column means that if a message containing that AVP is 
to be sent via a proxy/agent then the message MUST NOT be sent unless there is 
end-to-end security between the originator and the recipient or the originator has 
locally trusted configuration that indicates that end-to-end security is not needed.

========================

John