One document matched: draft-jwalker-cops-tls-00.txt

    Internet Draft                                 Jesse Walker 
    Expiration: December 2000                          Intel 
    File: draft-jwalker-cops-tls-00.txt                
                                                        
                                     
                             COPS Over TLS 
                       Last Updated: May 31, 2000 
 

Status of this Memo 
    
   This document is an Internet-Draft and is in full conformance with 
   all provisions of Section 10 of [RFC2026].  Internet-Drafts are 
   working documents of the Internet Engineering Task Force (IETF), its 
   areas, and its working groups.  Note that other groups may also 
   distribute working documents as Internet-Drafts. 
    
   Internet-Drafts are draft documents valid for a maximum of six 
   months and may be updated, replaced, or obsoleted by other documents 
   at any time.  It is inappropriate to use Internet-Drafts as 
   reference material or to cite them other than as "work in progress." 
    
      The list of current Internet-Drafts can be accessed at 
      http://www.ietf.org/ietf/1id-abstracts.txt 
    
      The list of Internet-Draft Shadow Directories can be 
      accessed at http://www.ietf.org/shadow.html. 
    
   To view the entire list of current Internet-Drafts, please check the 
   "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 
   Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern 
   Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific 
   Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). 
    
   Copyright (C) The Internet Society (2000). All Rights Reserved. 
    
Abstract 
    
   This memo describes how to use TLS to secure COPS connections over 
   the Internet. 
    
   Please send comments on this document to the rap@iphighway.com 
   mailing list. 
    
1.  Introduction 
    
   COPS [COPS] was designed to distribute cleartext policy information 
   from a centralized Policy Decision Point (PDP) to a set of Policy 
   Enforcement Points (PEP) in the Internet. COPS provides its own 
   security mechanisms to protect the per-hop integrity of the deployed 
   policy. However, the use of COPS for sensitive applications such as 
   some types of security policy distribution requires additional 
   security measures, such as data privacy. This is because some 
   organizations find it necessary to hide some or all of their security 


  
Walker et al.                                                 [Page 1] 

Internet Draft              COPS Over TLS                    May 2000 
 
 
   policies, e.g., because policy distribution to devices such as mobile 
   platforms can cross domain boundaries. 
    
   TLS [TLS] was designed to provide channel-oriented security. TLS 
   standardizes SSL and may be used with any connection oriented 
   service. TLS provides mechanisms for both one- and two-way 
   authentication, dynamic session keying, and data stream privacy and 
   integrity. 
    
   This document describes how to use COPS over TLS. "COPS over TLS" is 
   abbreviated COPS/TLS. 
    
1.1.  Requirements Terminology 
    
   Keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT" and 
   "MAY" that appear in this document are to be interpreted as described 
   in [RFC2119]. 
    
2.  COPS Over TLS 
    
   COPS/TLS is very simple: use COPS over TLS exactly as you would use 
   COPS over TCP. 
    
2.1.  Connection Initiation 
    
   The system acting as the PEP also acts as the TLS client. This system 
   initiates a connection to the PDP to the secure COPS port. When this 
   succeeds, the PEP system sends the TLS ClientHello to begin the TLS 
   handshake. When the TLS handshake completes, the PEP MAY initiate the 
   first COPS message. All COPS data MUST be sent as TLS "application 
   data". Normal COPS behavior follows. 
    
   All PEP implementations of COPS/TLS MUST support an access control 
   mechanism to identify authorized PDPs. This requirement provides a 
   level of assurance that the policy arriving at the PEP is actually 
   valid. The access control mechanism implemented is outside the scope 
   of this document. PEP implementations SHOULD require the use of this 
   access control mechanism for operation of COPS over TLS. When access 
   control is enabled, the PEP implementation MUST NOT initiate COPS/TLS 
   connections to systems not authorized as PDPs by the access control 
   mechanism. 
    
   Similarly, PDP COPS/TLS implementations MUST support an access 
   control mechanism permitting them to restrict their services to 
   authorized PEP systems only. Implementations MUST NOT require the use 
   of an access control mechanism at the PDP, however, as organizations 
   might not consider as sensitive the types of policy being deployed, 
   and therefore do not need to incur the expense of managing 
   credentials for the PEP systems. However, if access controls are 
   used, the PDP implementation MUST terminate COPS/TLS connections from 
   unauthorized PEP systems and log an error if an auditable logging 
   mechanism is present. 
    
  
Walker et al.           Expires December 2000                [Page 2] 

Internet Draft              COPS Over TLS                    May 2000 
 
 
2.2.  Connection Closure 
    
   TLS provides facilities to securely close its connections. Reception 
   of a valid closure alert assures an implementation that no further 
   data will arrive on that connection. The TLS specification requires 
   TLS implementations to initiate a closure alert exchange before 
   closing a connection. It permits TLS implementations to close 
   connections without waiting to receive closure alerts from the peer, 
   provided they send their own first. TLS allows implementations to 
   reuse the session in this case, but COPS/TLS makes no use of this 
   capability. 
    
   Note that a premature close does not call into question the security 
   of the data already received, but simply indicates that subsequent 
   data might have been truncated. Because TLS is oblivious to COPS 
   message boundaries, it is necessary to examine the COPS data itself 
   (specifically the Message header) to determine whether truncation 
   occurred. 
    
2.2.1.  PEP System Behavior 
    
   Because COPS uses connection closure to signal end of PDP data, PEP 
   implementations MUST treat premature closes as errors and any data 
   received as potentially truncated. The COPS protocol allows the PEP 
   system to find out whether truncation took place. A PEP system 
   detecting an incomplete close SHOULD recover gracefully. 
    
   PEP systems MUST send a closure alert before closing the connection. 
   Clients unprepared to receive any more data MAY choose not to wait 
   for the PDP system's closure alert and simply close the connection, 
   thus generating an incomplete close on the PDP side. 
    
2.2.2.  PDP System Behavior 
    
   COPS permits a PEP to close the connection at any time, and requires 
   PDPs to recover gracefully. In particular, PDPs SHOULD be prepared to 
   receive an incomplete close from the PEP, since a PEP often shuts 
   down for operational reasons unrelated to the transfer of policy 
   information between the PEP and PDP. 
     
      Implementation note: The PDP ordinarily expects to be able 
      to signal end of data by closing the connection. However, 
      the PEP may have already sent the closure alert and dropped 
      the connection. 
    
   PDP systems MUST attempt to initiate an exchange of closure alerts 
   with the PEP system before closing the connection. PDP systems MAY 
   close the connection after sending the closure alert, thus generating 
   an incomplete close on the PEP side. 
    
2.3.  Port Number 
    

  
Walker et al.           Expires December 2000                [Page 3] 

Internet Draft              COPS Over TLS                    May 2000 
 
 
   The first data a PDP expects to receive from the PEP is a Client-Open 
   message. The first data a TLS server (and hence a COPS/TLS server) 
   expects to receive is the ClientHello. Consequently, COPS/TLS runs 
   over a separate port in order to distinguish it from COPS alone. When 
   COPS/TLS runs over a TCP/IP connection, the default TCP port at the 
   PDP is TBD. The PEP may use any TCP port. This does not preclude 
   COPS/TLS from running over another transport. TLS only presumes a 
   reliable connection-oriented data stream. 
    
3.  Endpoint Identification and Access Control 
    
   Implementations of COPS/TLS implementations MUST use X.509 v3 
   certificates conforming to [PKIX] to identify PDP and PEP systems. 
   COPS/TLS systems MUST perform certificate verification processing 
   conforming to [PKIX]. 
    
   If a subjectAltName extension of type dNSName or iPAddress is present 
   in the PDPÆs certificate, that MUST be used as the PDP identity. 
   Otherwise, the most specific Common Name field in the Subject field 
   of the certificate MUST be used. 
    
   Matching is performed using the matching rules specified by [PKIX]. 
   If more than one identity of a given type is present in the 
   certificate (e.g. more than one dNSName name, a match in any one of 
   the set is considered acceptable.), the COPS system uses the first 
   name to match, except as noted below in the IP address checking 
   requirements. Names may contain the wildcard character * which is 
   considered to match any single domain name component or component 
   fragment. For example, *.a.com matches foo.a.com but not 
   bar.foo.a.com. f*.com matches foo.com but not bar.com. 
    
3.1.  PDP Identity 
    
   Generally, COPS/TLS requests are generated by the PEP consulting 
   bootstrap policy information identifying authorized PDPs. As a 
   consequence, the hostname or IP address for the PDP is known to the 
   PEP. How this bootstrap policy information arrives at the PEP is 
   outside the scope of this document. However, all PEP implementations 
   MUST provide a mechanism to securely deliver or configure the 
   bootstrap policy. In particular, all PEP implementations MUST support 
   a mechanism to securely acquire the signing certificate of the 
   authorized certificate authorities issuing PDP certificates, and MUST 
   support a mechanism to securely acquire an access control list or 
   filter identifying its set of authorized PDPs. 
    
   PEP implementations that participate in multiple domains, such as 
   those on mobile platforms, MAY use different certificate authorities 
   and access control lists in each domain. 
    
   Organizations may choose to deliver some or all of the bootstrap 
   policy configuration from an untrusted source, such as DHCP. In these 
   circumstance, COPS over TLS provides no protection from attack when 
   this untrusted source is compromised. 
  
Walker et al.           Expires December 2000                [Page 4] 

Internet Draft              COPS Over TLS                    May 2000 
 
 
    
   If the PDP hostname or IP address is available via the access control 
   mechanism, the PEP MUST check it against the PDP's identity as 
   presented in the PDP's TLS Certificate message. 
    
   In some cases the bootstrap policy will identify the authorized PDP 
   only by an IP address of the PDP system. In this case, the 
   subjectAltName MUST be present in the certificate, and it MUST 
   include an iPAdress format matching the expected name of the policy 
   server. 
    
   If the hostname of the PDP does not match the identity in the 
   certificate, a PEP on a user oriented system MUST either notify the 
   user (PEP systems MAY afford the user the opportunity to continue 
   with the connection in any case) or terminate the connection with a 
   bad certificate error. PEPs on unattended systems MUST log the error 
   to an appropriate audit log (if available) and MUST terminate the 
   connection (with a bad certificate error). Unattended PEP systems MAY 
   provide a configuration setting that disables this check, but then 
   MUST provide a setting which enables it. 
    
3.2.  PEP Identity 
    
   When PEP systems are not access controlled, the PDP need have no 
   external knowledge of what the PEP's identity ought to be and so 
   checks are neither possible nor necessary. In this case, there is no 
   requirement for PEP systems to register with a certificate authority, 
   and COPS over TLS uses one-way authentication, of the PDP to the PEP. 
    
   When PEP systems are access controlled, PEPs must be PKI clients in 
   the sense of [PKIX]. In this case, COPS over TLS uses two-way 
   authentication, and the PDP MUST perform the same identity checks for 
   the PEPs as described above for the PDP. 
    
   When access controls are in effect at the PDP, PDP implementations 
   MUST have a mechanism to securely acquire the signing certificates of 
   the certificate authorities issuing certificates to any of the PEPs 
   they support. 
    
4.  IANA Considerations 
    
   COPS over TLS uses a separate TCP port from COPS. IANA should assign 
   the value TBD to this port. 
    
5.  Security Considerations 
    
   This entire document concerns security. 
    
6.  Acknowledgements 
    
   This document freely plagiarizes and adapts Eric Rescorla's similar 
   document draft-ietf-tls-http-xx.txt that specifies how HTTP runs over 

  
Walker et al.           Expires December 2000                [Page 5] 

Internet Draft              COPS Over TLS                    May 2000 
 
 
   TLS. Discussions with David Durham and Ylian Sainte-Hillaire also 
   lead to improvements in this document. 
    
7.  References 
    
   [COPS] Durham, D., Boyle, J., Cohen, R., Herzog, R., Rajan, R., 
   Sastry, A., "The COPS (Common Open Policy Service) Protocol", RFC 
   2748, January 200. 
    
   [PKIX] Housley, R., Ford, W., Polk, W., Solo, D., "Internet Public 
   Key Infrastructure: Part I: X.509 Certificate and CRL Profile", RFC 
   2459, January 1999. 
    
   [RFC2026] Bradner, S., "The Internet Standards Process - Revision 3", 
   RFC 2026, October 1996 
    
   [RFC2119] Bradner, S., "Key Words for use in RFCs to indicate 
   Requirement Levels", RFC 2119, March 1997. 
    
   [TLS] Dierks, T., Allen, C., "The TLS Protocol", RFC2246, January 
   1999. 
    
8.  Author Addresses 
    
   Jesse R. Walker 
   Intel Corporation 
   2111 N.E. 25th Avenue 
   Hillsboro, OR  97214 
   USA 
   jesse.walker@intel.com 
    
9.  Full Copyright Statement 
    
   Copyright (C) The Internet Society (2000). All Rights Reserved. 
    
   This document and translations of it may be copied and furnished to 
   others, and derivative works that comment on or otherwise explain it 
   or assist in its implementation may be prepared, copied, published 
   and distributed, in whole or in part, without restriction of any 
   kind, provided that the above copyright notice and this paragraph 
   are included on all such copies and derivative works.  In addition, 
   the ASN.1 modules presented in Appendices A and B may be used in 
   whole or in part without inclusion of the copyright notice.  
   However, this document itself may not be modified in any way, such 
   as by removing the copyright notice or references to the Internet 
   Society or other Internet organizations, except as needed for the 
   purpose of developing Internet standards in which case the 
   procedures for copyrights defined in the Internet Standards process 
   shall be followed, or as required to translate it into languages 
   other than English. 
    
   The limited permissions granted above are perpetual and will not be 
   revoked by the Internet Society or its successors or assigns. This 
  
Walker et al.           Expires December 2000                [Page 6] 

Internet Draft              COPS Over TLS                    May 2000 
 
 
   document and the information contained herein is provided on an "AS 
   IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK 
   FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT 
   NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN 
   WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 
    
 














































  
Walker et al.           Expires December 2000                [Page 7]