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

From: <[email-masked]>
Date: Thu, 25 Apr 2002 10:25:23 +0300

Hi all,

David Spence proposed the following for seperation of CMS dependencies
from the other drafts.  Please review this & send comments.

The current plan is to adopt the approach, with some additional comments,
etc. once I get to editing the document.

thanks,
John

From: David Spence:

Last week Frederik Johansson, Tony Johansson, Bob Kopacz, John 
Vollbrecht, and I discussed the problem of how to remove normative 
references to CMS from the first batch of Diameter drafts to be 
standardized.  This message documents our conclusions and may be 
considered as a proposal for resolving this issue in all the drafts.  In 
writing up this proposal I may have embellished or even misunderstood 
the sense of the conversation.  

I have not drafted any actual text to implement this proposal but would 
be glad to once we reach consensus as to how to proceed.

One final hint.  Use a fixed width font to display the outline below or 
it will look very ugly.

                  Proposal for Resolution of Issue 321
                      Normative references to CMS

I. The Basic Ideas

   A. Diameter base, transport, and MobileIPv4 should progress before 
      CMS Security.
      
      Diameter is useful in many situations without end-to-end security 
      and should be standardized as quickly as possible.  We have made 
      sufficient progress on end-to-end security that we may discuss it 
      in the base draft with some confidence.  Nevertheless, we believe 
      it unwise to submit the Diameter CMS Security draft as a proposed 
      standard at this time because we believe that actual 
      implementation and interoperability experience will be crucial to 
      the process of creating a useful and correct specification.
      
   B. The framework for Diameter end-to-end security can be described in 
      the base.  The concepts defined in the base may then be referenced 
      in Diameter applications.  All references to CMS, normative or 
      otherwise, can then be removed from Diameter applications.  The 
      base can make a single non-normative reference to the Diameter CMS 
      Security draft as a work in progress toward defining an end-to-end 
      security extension [1] for Diameter.
            
II. The Principles

   A. Define End-to-End Security in the terminology section.
   
   B. CMS references in the base will need to be handled on a case by 
      case basis.  Recommendations are given following this outline.
   
   C. Generally, CMS references in Diameter applications should be 
      replaced with references to the generic term end-to-end security.
      
   D. The only reference to the CMS-sec draft itself should be a 
      non-normative reference in the end-to-end security section of the 
      base (see E, below), where it should be listed as work in progress 
      toward an end-to-end security extension to Diameter.
   
   E. Add a section (perhaps a subsection of section 2, Protocol 
      Overview) to discuss the end-to-end security framework.
      
      1. Present the basic components of end-to-end security including 
         encryption and message origin authentication.
         
      2. Define additional terms that may be referenced in the 
         applications.
         
         a. Security Association
         
         b. A generic term for the DSAR/DSAA message exchange.
            
      3. Indicate that end-to-end security is to be provided by an 
         end-to-end security extension.
         
         a. Emphasize that this is not included in the base protocol.
         
         b. Cite the CMS draft as a work in progress toward a possible 
            end-to-end security extension.
         
      4. The circumstances requiring the use of end-to-end security are 
         determined by service provider policy.
         
         a. This policy is not the subject of standardization.
         
         b. This policy may be indexed by next hop Diameter peer or by 
            destination realm.
         
         c. Possible granularity for use of end-to-end security may be:
         
            1) Never use end-to-end security if the condition is met.
            
            2) Use end-to-end security on messages containing sensitive 
               AVPs if the condition is met.  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.
               
            3) Always use end-to-end security if the condition is met.
               
      5. Discuss situations in which end-to-end security may be 
         required.  Also mention situations such as trusted brokers and 
         settlement agents for which end-to-end security should not be 
         used.
      
   E. Diameter applications should alert implementors to potentially 
      sensitive situations where end-to-end security policy SHOULD 
      (MUST?) be consulted.
      
      Diameter-MIP contains such alerts for the key AVPs.  Diameter-MIP 
      should specify that if policy requires end-to-end security and an 
      end-to-end security association cannot be established then the 
      request should be denied with the specified error code.
      
   F. There are two possibilities for how to handle the P bit and may 
      encrypt column.  I'm not sure what we decided in our conversation 
      or what would be most appropriate.  Please comment.  Alternative 
      1, below grants the most flexibility to the end-to-end security 
      extension itself.  Alternative 2 allows implementors to prepare 
      for adding an end-to-end security extension later.  Here are the 
      two alternatives.
      
      1. Make no mention of the P bit in the base or applications and 
         delete the may encrypt column.  Move this to the CMS-sec draft 
         for the base protocol and any applications already defined.
         
      2. Define the P bit and the meaning of the may encrypt column in 
         the base as part of the requirements for end-to-end security.

End Notes
      
   [1] We currently use the term Diameter Application for all extensions 
       to Diameter.  I suggest we reserve the term Diameter Application 
       to refer to actual applications such as MobileIPv4 and NASREQ, 
       and use the term Diameter Extension for extensions to Diameter 
       that may be used orthogonal to the applications.  Both would be 
       numbered out of the same name space, and both could be included 
       in AVPs such as the *-Application-Id AVPs.  (Should CMS-sec be 
       included in both Auth-Application-Id and Acct-Application-ID?)  

                           *   *   *   *   *

Recommendations for Handling CMS References in the Base Draft

   1. Remove mention of CMS-sec from section 1.1.2, Description of 
      the Document Set.
   
   2. Remove mention of CMS-sec from the beginning of section 2, 
      Protocol Overview.
   
   3. Delete the CMS-sec application identifier from section 2.4.
      
   4. Replace the CMS references in section 2.8.2, Proxy Agents, with 
      references to end-to-end security.
      
   5. In section 4.1, AVP Header, what to do with the CMS reference will 
      depend on what we decide to do with the P bit.  (See principle 
      II.F. in the outline, above.
      
   6. Replace the CMS reference in section 4.6, Diameter Base 
      Protocol AVPs with a reference to end-to-end security.
   
   7. The reference to the AAA-Node-Cert AVP in sec. 6.1.7 should be 
      removed.  The sentences:
      
         Redirect agents MAY also include the certificate of the 
         servers in the Redirect-Host AVP(s). These certificates are 
         encapsulated in a AAA-Node-Cert AVP [CMS].
      
      are inappropriate anyway.  Since the Diameter node receiving the 
      redirect will be creating a peer-to-peer connection to the 
      Redirect-Host, there is no need for end-to-end security.
   
   8. The error code 5010, DIAMETER_UNSUPPORTED_TRANSFORM, should be 
      removed from section 7.1.5, Permanent Failures.  This code 
      should be defined in the CMS-sec draft.
      
   9. References to AVPs defined in CMS-sec in section 9.5, 
      Accounting Records, should be relaxed to a more general 
      reference to the use of end-to-end security.
      
  10. The following paragraph should be moved from section 9.7.1, 
      Accounting Request, to CMS-sec.

         When the Accounting-Request is being submitted to a third 
         party (e.g. settlement service), and includes the 
         CMS-Signed-Data AVP [CMS], the CMS-Signed-Data AVP MUST be 
         signed by both the local and home Diameter server using the 
         countersignature procedures described in [CMS].

      Actually, I don't think this paragraph is even correct.  The 
      home Diameter server is the ultimate destination of the 
      Accounting-Request.  So why should it countersign?  I suspect 
      it is the third party that should countersign.  Also, is the 
      term "local Diameter server" defined anywhere?  If not, then 
      use another term -- such as origin Diameter node, origin host, 
      or "the Diameter node indicated by the Origin-Host AVP".
   
  11. The following sentences in 9.7.2, accounting answer should be 
      replaced:
   
         If the CMS-Data AVP was present in the Accounting-Request, 
         the corresponding ACA message MUST include the CMS-Data AVP 
         signed by the responder to provide strong AVP 
         authentication, which MAY be used for the purposes of 
         repudiation.
         
      For example, state:
      
         If the Accounting-Request was protected by end-to-end 
         security, then the corresponding ACA message MUST be 
         protected by end-to-end security.
         
      The nonsense about being "used for the purposes of repudiation" 
      should be deleted altogether.
      
  12. The following paragraph in section 13, Security Considerations, 
      is just wrong.
      
         When third party brokers or redirect agents are used, 
         strong application level security SHOULD be required, such 
         as non- repudiation. When the communicating peers do require 
         this level of security either for legal or business 
         purposes, the Diameter application defined in [CMS] MAY be 
         used. This security model provides AVP-level authentication, 
         and the encryption mechanism is designed such that only the 
         target host has the keying information required to decrypt 
         the information.
         
      It has so many problems, I don't know where to start.  First of 
      all, the use of third party brokers does not necessarily 
      indicate that end-to-end security SHOULD be used.  Secondly, 
      end-to-end security is useless with the redirect model.  Think 
      about it.  If I need to use a redirect agent in order to find 
      out what server to send the message to, then how can I create a 
      security association with that server?  If you want to keep 
      AVPs private from your redirect agent, then don't send them to 
      your redirect agent!  Third, what do we mean by "such as 
      non-repudiation"?  Fourth, the term "communicating peers" is a 
      bad choice of words.  We use the term peers exclusively to talk 
      about directly connected Diameter nodes.  After fixing all 
      those problems, replace the reference to CMS with a reference 
      to end-to-end security.
      
  13. I don't understand the reference to CMS in section 13.2 TLS 
      Usage so I'm not sure how to fix it.
      
  14. Delete the references to CMS in Appendix A.