RFC4261 日本語訳
4261 Common Open Policy Service (COPS) Over Transport Layer Security(TLS). J. Walker, A. Kulkarni, Ed.. December 2005. (Format: TXT=28662 bytes) (Updates RFC2748) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group J. Walker Request for Comments: 4261 A. Kulkarni, Ed. Updates: 2748 Intel Corp. Category: Standards Track December 2005
Network Working Group J. Walker Request for Comments: 4261 A. Kulkarni, Ed. Updates: 2748 Intel Corp. Category: Standards Track December 2005
Common Open Policy Service (COPS)
Over Transport Layer Security (TLS)
Common Open Policy Service (COPS) Over Transport Layer Security (TLS)
Status of This Memo
Status of This Memo
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright Notice
Copyright (C) The Internet Society (2005).
Copyright (C) The Internet Society (2005).
Abstract
Abstract
This document describes how to use Transport Layer Security (TLS) to secure Common Open Policy Service (COPS) connections over the Internet.
This document describes how to use Transport Layer Security (TLS) to secure Common Open Policy Service (COPS) connections over the Internet.
This document also updates RFC 2748 by modifying the contents of the Client-Accept message.
This document also updates RFC 2748 by modifying the contents of the Client-Accept message.
Walker & Kulkarni Standards Track [Page 1] RFC 4261 COPS Over TLS December 2005
Walker & Kulkarni Standards Track [Page 1] RFC 4261 COPS Over TLS December 2005
Table Of Contents
Table Of Contents
1. Introduction ....................................................2
2. COPS Over TLS ...................................................3
3. Separate Ports versus Upward Negotiation ........................3
4. COPS/TLS Objects and Error codes ................................4
4.1. The TLS Message Integrity Object (Integrity-TLS) ...........4
4.2. Error Codes ................................................4
5. COPS/TLS Secure Connection Initiation ...........................5
5.1. PEP Initiated Security Negotiation .........................5
5.2. PDP Initiated Security Negotiation .........................6
6. Connection Closure ..............................................7
6.1. PEP System Behavior ........................................7
6.2. PDP System Behavior ........................................8
7. Endpoint Identification and Access Control ......................8
7.1. PEP Identity ...............................................9
7.2. PDP Identity ...............................................9
8. Cipher Suite Requirements ......................................10
9. Backward Compatibility .........................................10
10. IANA Considerations ...........................................10
11. Security Considerations .......................................11
12. Acknowledgements ..............................................11
13. References ....................................................12
13.1. Normative References .....................................12
13.2. Informative References ...................................12
1. Introduction ....................................................2 2. COPS Over TLS ...................................................3 3. Separate Ports versus Upward Negotiation ........................3 4. COPS/TLS Objects and Error codes ................................4 4.1. The TLS Message Integrity Object (Integrity-TLS) ...........4 4.2. Error Codes ................................................4 5. COPS/TLS Secure Connection Initiation ...........................5 5.1. PEP Initiated Security Negotiation .........................5 5.2. PDP Initiated Security Negotiation .........................6 6. Connection Closure ..............................................7 6.1. PEP System Behavior ........................................7 6.2. PDP System Behavior ........................................8 7. Endpoint Identification and Access Control ......................8 7.1. PEP Identity ...............................................9 7.2. PDP Identity ...............................................9 8. Cipher Suite Requirements ......................................10 9. Backward Compatibility .........................................10 10. IANA Considerations ...........................................10 11. Security Considerations .......................................11 12. Acknowledgements ..............................................11 13. References ....................................................12 13.1. Normative References .....................................12 13.2. Informative References ...................................12
1. Introduction
1. Introduction
COPS [RFC2748] was designed to distribute clear-text 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 (e.g., some types of security policy distribution) requires additional security measures, such as data confidentiality. This is because some organizations find it necessary to hide some or all of their security policies, e.g., because policy distribution to devices such as mobile platforms can cross domain boundaries.
COPS [RFC2748] was designed to distribute clear-text 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 (e.g., some types of security policy distribution) requires additional security measures, such as data confidentiality. This is because some organizations find it necessary to hide some or all of their security policies, e.g., because policy distribution to devices such as mobile platforms can cross domain boundaries.
TLS [RFC2246] 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.
TLS [RFC2246] 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.
This document describes how to use COPS over TLS. "COPS over TLS" is abbreviated COPS/TLS.
Walker & Kulkarni Standards Track [Page 2] RFC 4261 COPS Over TLS December 2005
Walker & Kulkarni Standards Track [Page 2] RFC 4261 COPS Over TLS December 2005
Glossary
Glossary
COPS - Common Open Policy Service. See [RFC2748].
COPS - Common Open Policy Service. See [RFC2748].
COPS/TCP - A plain-vanilla implementation of COPS.
COPS/TCP - A plain-vanilla implementation of COPS.
COPS/TLS - A secure implementation of COPS using TLS.
COPS/TLS - A secure implementation of COPS using TLS.
PDP - Policy Decision Point. Also referred to as the Policy Server.
See [RFC2753].
PDP - Policy Decision Point. Also referred to as the Policy Server. See [RFC2753].
PEP - Policy Enforcement Point. Also referred to as the Policy
Client. See [RFC2753].
PEP - Policy Enforcement Point. Also referred to as the Policy Client. See [RFC2753].
Conventions used in this document
Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
2. COPS Over TLS
2. COPS Over TLS
COPS/TLS is very simple: use COPS over TLS similar to how you would use COPS over TCP (COPS/TCP). Apart from a specific procedure used to initialize the connection, there is no difference between COPS/TLS and COPS/TCP.
COPS/TLS is very simple: use COPS over TLS similar to how you would use COPS over TCP (COPS/TCP). Apart from a specific procedure used to initialize the connection, there is no difference between COPS/TLS and COPS/TCP.
3. Separate Ports versus Upward Negotiation
3. Separate Ports versus Upward Negotiation
There are two ways in which insecure and secure versions of the same protocol can be run simultaneously.
There are two ways in which insecure and secure versions of the same protocol can be run simultaneously.
In the first method, the secure version of the protocol is also allocated a well-known port. This strategy of having well-known port numbers for both, the secure and insecure versions, is known as 'Separate Ports'. The clients requiring security can simply connect to the well-known secure port. This method is easy to implement, with no modifications needed to existing insecure implementations. The disadvantage, however, is that it doesn't scale well, because a new port is required for each secure implementation. More problems with this approach have been listed in [RFC2595].
In the first method, the secure version of the protocol is also allocated a well-known port. This strategy of having well-known port numbers for both, the secure and insecure versions, is known as 'Separate Ports'. The clients requiring security can simply connect to the well-known secure port. This method is easy to implement, with no modifications needed to existing insecure implementations. The disadvantage, however, is that it doesn't scale well, because a new port is required for each secure implementation. More problems with this approach have been listed in [RFC2595].
The second method is known as 'Upward Negotiation'. In this method, the secure and insecure versions of the protocol run on the same port. The client connects to the server, both discover each others' capabilities, and start security negotiations if desired. This method usually requires some changes to the protocol being secured.
The second method is known as 'Upward Negotiation'. In this method, the secure and insecure versions of the protocol run on the same port. The client connects to the server, both discover each others' capabilities, and start security negotiations if desired. This method usually requires some changes to the protocol being secured.
Walker & Kulkarni Standards Track [Page 3] RFC 4261 COPS Over TLS December 2005
Walker & Kulkarni Standards Track [Page 3] RFC 4261 COPS Over TLS December 2005
In view of the many issues with the Separate Ports approach, the authors have decided to use the Upward Negotiation method for COPS/TLS.
In view of the many issues with the Separate Ports approach, the authors have decided to use the Upward Negotiation method for COPS/TLS.
4. COPS/TLS Objects and Error codes
4. COPS/TLS Objects and Error codes
This section describes the COPS objects and error codes needed to support COPS/TLS.
This section describes the COPS objects and error codes needed to support COPS/TLS.
4.1. The TLS Message Integrity Object (Integrity-TLS)
4.1. The TLS Message Integrity Object (Integrity-TLS)
The TLS Integrity object is used by the PDP and the PEP to start the TLS negotiation. This object should be included only in the Client- Open or Client-Accept messages. It MUST NOT be included in any other COPS message.
The TLS Integrity object is used by the PDP and the PEP to start the TLS negotiation. This object should be included only in the Client- Open or Client-Accept messages. It MUST NOT be included in any other COPS message.
0 1 2 3
0 1 2 3
+----------+----------+----------+----------+
| Length (Octets) | C-Num=16 | C-Type=2 |
+----------+----------+----------+----------+
| //////// | Flags |
+----------+----------+----------+----------+
+----------+----------+----------+----------+ | Length (Octets) | C-Num=16 | C-Type=2 | +----------+----------+----------+----------+ | //////// | Flags | +----------+----------+----------+----------+
Note: //// implies the field is reserved, set to 0, and should
be ignored on receipt.
Note: //// implies the field is reserved, set to 0, and should be ignored on receipt.
Flags: 16 bits
0x01 = StartTLS
This flag indicates that the sender of the message
wishes to initiate a TLS handshake.
Flags: 16 bits 0x01 = StartTLS This flag indicates that the sender of the message wishes to initiate a TLS handshake.
The Client-Type of any message containing this object MUST be 0. Client-Type 0 is used to negotiate COPS connection level security and must only be used during the connection establishment phase. Please refer to section 4.1 of [RFC2748] for more details.
The Client-Type of any message containing this object MUST be 0. Client-Type 0 is used to negotiate COPS connection level security and must only be used during the connection establishment phase. Please refer to section 4.1 of [RFC2748] for more details.
4.2. Error Codes
4.2. Error Codes
This section uses the error codes described in section 2.2.8 (Error Object) of [RFC2748].
This section uses the error codes described in section 2.2.8 (Error Object) of [RFC2748].
Error Code: 13= Unknown COPS Object:
Error Code: 13= Unknown COPS Object:
Walker & Kulkarni Standards Track [Page 4] RFC 4261 COPS Over TLS December 2005
Walker & Kulkarni Standards Track [Page 4] RFC 4261 COPS Over TLS December 2005
Sub-code (octet 2) contains the unknown object's C-Num, and (octet 3) contains unknown object's C-Type. If the PEP or PDP does not support TLS, the C-Num specified MUST be 16 and the C-Type MUST be 2. This demonstrates that the TLS version of the Integrity object is not known.
Sub-code (octet 2) contains the unknown object's C-Num, and (octet 3) contains unknown object's C-Type. If the PEP or PDP does not support TLS, the C-Num specified MUST be 16 and the C-Type MUST be 2. This demonstrates that the TLS version of the Integrity object is not known.
This error code MUST be used by either PEP or PDP to indicate a security-related connection closure if it cannot support a TLS connection for the COPS protocol.
This error code MUST be used by either PEP or PDP to indicate a security-related connection closure if it cannot support a TLS connection for the COPS protocol.
If the PDP wishes to negotiate a different security mechanism than requested by the PEP in the Client-Open, it MUST send the following error code:
If the PDP wishes to negotiate a different security mechanism than requested by the PEP in the Client-Open, it MUST send the following error code:
Error Code: 15= Authentication Required
Error Code: 15= Authentication Required
Where the Sub-code (octet 2) contains the C-Num=16 value for the Integrity Object and (octet 3) MUST specify the PDP required/preferred Integrity object C-Type. If the server does not support any form of COPS-Security, it MUST set the Sub-code (octet 2) to 16 and (octet 3) to zero instead, signifying that no type of the Integrity object is supported.
Where the Sub-code (octet 2) contains the C-Num=16 value for the Integrity Object and (octet 3) MUST specify the PDP required/preferred Integrity object C-Type. If the server does not support any form of COPS-Security, it MUST set the Sub-code (octet 2) to 16 and (octet 3) to zero instead, signifying that no type of the Integrity object is supported.
5. COPS/TLS Secure Connection Initiation
5. COPS/TLS Secure Connection Initiation
Security negotiation may be initiated by either the PDP or the PEP. The PEP can initiate a negotiation via a Client-Open message, while a PDP can initiate a negotiation via a Client-Accept message.
Security negotiation may be initiated by either the PDP or the PEP. The PEP can initiate a negotiation via a Client-Open message, while a PDP can initiate a negotiation via a Client-Accept message.
Once the TLS connection is established, all COPS data MUST be sent as TLS "application data".
Once the TLS connection is established, all COPS data MUST be sent as TLS "application data".
5.1. PEP Initiated Security Negotiation
5.1. PEP Initiated Security Negotiation
A PEP MAY initiate a TLS security negotiation with a PDP using the Client-Open message. To do this, the Client-Open message MUST have a Client-Type of 0 and MUST include the Integrity-TLS object.
A PEP MAY initiate a TLS security negotiation with a PDP using the Client-Open message. To do this, the Client-Open message MUST have a Client-Type of 0 and MUST include the Integrity-TLS object.
Upon receiving the Client-Open message, the PDP SHOULD respond with a Client-Accept message containing the Integrity-TLS object.
Upon receiving the Client-Open message, the PDP SHOULD respond with a Client-Accept message containing the Integrity-TLS object.
Note that in order to carry the Integrity-TLS object, the contents of the Client-Accept message defined in section 3.7 of [RFC2748] need not change, except that the C-Type of the integrity object contained there-in should now be C-Type=2. For Example:
Note that in order to carry the Integrity-TLS object, the contents of the Client-Accept message defined in section 3.7 of [RFC2748] need not change, except that the C-Type of the integrity object contained there-in should now be C-Type=2. For Example:
Walker & Kulkarni Standards Track [Page 5] RFC 4261 COPS Over TLS December 2005
Walker & Kulkarni Standards Track [Page 5] RFC 4261 COPS Over TLS December 2005
<Client-Accept> ::= <Common Header>
<KA Timer>
[<ACCT Timer>]
[<Integrity (C-Num=16, C-Type=2)>]
<Client-Accept> ::= <Common Header> <KA Timer> [<ACCT Timer>] [<Integrity (C-Num=16, C-Type=2)>]
Note also that this new format of the Client-Accept message does not replace or obsolete the existing Client-Accept message format, which can continue to be used for non-secure COPS session negotiations.
Note also that this new format of the Client-Accept message does not replace or obsolete the existing Client-Accept message format, which can continue to be used for non-secure COPS session negotiations.
Upon receiving the appropriate Client-Accept message, the PEP SHOULD initiate the TLS handshake.
Upon receiving the appropriate Client-Accept message, the PEP SHOULD initiate the TLS handshake.
The message exchange is as follows:
The message exchange is as follows:
C: Client-Open (Client-Type = 0, Integrity-TLS)
S: Client-Accept (Client-Type = 0, Integrity-TLS)
<TLS handshake>
C/S: <...further messages...>
C: Client-Open (Client-Type = 0, Integrity-TLS) S: Client-Accept (Client-Type = 0, Integrity-TLS) <TLS handshake> C/S: <...further messages...>
In case the PDP does not wish to open a secure connection with the PEP, it MUST reply with a Client-Close message and close the connection. The Client-Close message MUST include the error code 15= Authentication required, with the Sub-code (octet 2) set to 16 for the Integrity object's C-Num, and (octet 3) set to the C-Type corresponding to the server's preferred Integrity type, or zero for no security.
In case the PDP does not wish to open a secure connection with the PEP, it MUST reply with a Client-Close message and close the connection. The Client-Close message MUST include the error code 15= Authentication required, with the Sub-code (octet 2) set to 16 for the Integrity object's C-Num, and (octet 3) set to the C-Type corresponding to the server's preferred Integrity type, or zero for no security.
A PEP requiring the Integrity-TLS object in a Client-Accept message MUST close the connection if the Integrity-TLS object is missing. The ensuing Client-Close message MUST include the error code 15= Authentication required, with the Sub-code (octet 2) containing the required Integrity object's C-Num=16, and (octet 3) containing the required Integrity object's C-Type=2.
A PEP requiring the Integrity-TLS object in a Client-Accept message MUST close the connection if the Integrity-TLS object is missing. The ensuing Client-Close message MUST include the error code 15= Authentication required, with the Sub-code (octet 2) containing the required Integrity object's C-Num=16, and (octet 3) containing the required Integrity object's C-Type=2.
5.2. PDP Initiated Security Negotiation
5.2. PDP Initiated Security Negotiation
The PEP initially opens a TCP connection with the PDP on the standard COPS port and sends a Client-Open message. This Client-Open message MUST have a Client-Type of 0.
The PEP initially opens a TCP connection with the PDP on the standard COPS port and sends a Client-Open message. This Client-Open message MUST have a Client-Type of 0.
The PDP SHOULD then reply with a Client-Accept message. In order to signal the PEP to start the TLS handshake, the PDP MUST include the Integrity-TLS object in the Client-Accept message.
The PDP SHOULD then reply with a Client-Accept message. In order to signal the PEP to start the TLS handshake, the PDP MUST include the Integrity-TLS object in the Client-Accept message.
Upon receiving the Client-Accept message with the Integrity-TLS object, the PEP SHOULD initiate the TLS handshake. If for any reason the PEP cannot initiate the handshake, it MUST close the connection.
Upon receiving the Client-Accept message with the Integrity-TLS object, the PEP SHOULD initiate the TLS handshake. If for any reason the PEP cannot initiate the handshake, it MUST close the connection.
Walker & Kulkarni Standards Track [Page 6] RFC 4261 COPS Over TLS December 2005
Walker & Kulkarni Standards Track [Page 6] RFC 4261 COPS Over TLS December 2005
The message exchange is as follows:
The message exchange is as follows:
C: Client-Open (Client-Type = 0)
S: Client-Accept (Client-Type = 0, Integrity-TLS)
<TLS handshake>
C/S: <...further messages...>
C: Client-Open (Client-Type = 0) S: Client-Accept (Client-Type = 0, Integrity-TLS) <TLS handshake> C/S: <...further messages...>
After receiving the Client-Accept, the PEP MUST NOT send any messages until the TLS handshake is complete. Upon receiving any message from the PEP before the TLS handshake starts, the PDP MUST issue a Client-Close message with an error code 15= Authentication Required.
After receiving the Client-Accept, the PEP MUST NOT send any messages until the TLS handshake is complete. Upon receiving any message from the PEP before the TLS handshake starts, the PDP MUST issue a Client-Close message with an error code 15= Authentication Required.
A PDP wishing to negotiate security with a PEP having an existing non-secure connection MUST send a Client-Close with the error code 15= Authentication required, with the Sub-code (octet 2) containing the required Integrity object's C-Num=16, and (octet 3) containing the required Integrity object's C-Type=2, and then wait for the PEP to reconnect. Upon receiving the Client-Open message, it SHOULD use the Client-Accept message to initiate security negotiation.
A PDP wishing to negotiate security with a PEP having an existing non-secure connection MUST send a Client-Close with the error code 15= Authentication required, with the Sub-code (octet 2) containing the required Integrity object's C-Num=16, and (octet 3) containing the required Integrity object's C-Type=2, and then wait for the PEP to reconnect. Upon receiving the Client-Open message, it SHOULD use the Client-Accept message to initiate security negotiation.
6. Connection Closure
6. 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 also permits TLS implementations to close connections without waiting to receive closure alerts from the peer, provided they send their own first. A connection closed in this way is known as an "incomplete close". TLS allows implementations to reuse the session in this case, but COPS/TLS makes no use of this capability.
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 also permits TLS implementations to close connections without waiting to receive closure alerts from the peer, provided they send their own first. A connection closed in this way is known as an "incomplete close". TLS allows implementations to reuse the session in this case, but COPS/TLS makes no use of this capability.
A connection closed without first sending a closure alert is known as a "premature close". 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.
A connection closed without first sending a closure alert is known as a "premature close". 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.
6.1. PEP System Behavior
6.1. PEP System Behavior
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 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.
Walker & Kulkarni Standards Track [Page 7] RFC 4261 COPS Over TLS December 2005
Walker & Kulkarni Standards Track [Page 7] RFC 4261 COPS Over TLS December 2005
PEP systems SHOULD send a closure alert before closing the connection. PEPs 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.
PEP systems SHOULD send a closure alert before closing the connection. PEPs 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.
6.2. PDP System Behavior
6.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.
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 the end of data by closing the connection. However, the
PEP may have already sent the closure alert and dropped the
connection.
Implementation note: The PDP ordinarily expects to be able to signal the 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.
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.
7. Endpoint Identification and Access Control
7. Endpoint Identification and Access Control
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. PEP deployments 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.
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. PEP deployments 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. However, deployments MAY choose not to use an access control mechanism at the PDP, as organizations might not consider the types of policy being deployed as sensitive, and therefore do not need to incur the expense of managing credentials for the PEP systems. If access controls are used, however, the PDP implementation MUST terminate COPS/TLS connections from unauthorized PEP systems and log an error if an auditable logging mechanism is present.
Similarly, PDP COPS/TLS implementations MUST support an access control mechanism permitting them to restrict their services to authorized PEP systems only. However, deployments MAY choose not to use an access control mechanism at the PDP, as organizations might not consider the types of policy being deployed as sensitive, and therefore do not need to incur the expense of managing credentials for the PEP systems. If access controls are used, however, the PDP implementation MUST terminate COPS/TLS connections from unauthorized PEP systems and log an error if an auditable logging mechanism is present.
Implementations of COPS/TLS MUST use X.509 v3 certificates conforming to [RFC3280] to identify PDP and PEP systems. COPS/TLS systems MUST perform certificate verification processing conforming to [RFC3280].
Implementations of COPS/TLS MUST use X.509 v3 certificates conforming to [RFC3280] to identify PDP and PEP systems. COPS/TLS systems MUST perform certificate verification processing conforming to [RFC3280].
Walker & Kulkarni Standards Track [Page 8] RFC 4261 COPS Over TLS December 2005
Walker & Kulkarni Standards Track [Page 8] RFC 4261 COPS Over TLS December 2005
If a subjectAltName extension of type dNSName or iPAddress is present in the PDP's certificate, it MUST be used as the PDP identity. If both types are present, dNSName SHOULD be used as the PDP identity. If neither type is present, the most specific Common Name field in the Subject field of the certificate SHOULD be used.
If a subjectAltName extension of type dNSName or iPAddress is present in the PDP's certificate, it MUST be used as the PDP identity. If both types are present, dNSName SHOULD be used as the PDP identity. If neither type is present, the most specific Common Name field in the Subject field of the certificate SHOULD be used.
Matching is performed using the matching rules specified by [RFC3280]. If more than one identity of a given type is present in the certificate (e.g., more than one dNSName in the subjectAltName certificate extension), a match in any one of the provided identities is acceptable. Generally, the COPS system uses the first name for matching, except as noted below in the IP address checking requirements.
Matching is performed using the matching rules specified by [RFC3280]. If more than one identity of a given type is present in the certificate (e.g., more than one dNSName in the subjectAltName certificate extension), a match in any one of the provided identities is acceptable. Generally, the COPS system uses the first name for matching, except as noted below in the IP address checking requirements.
7.1. PEP Identity
7.1. PEP Identity
When PEP systems are not access controlled, the PDP does not need 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 not access controlled, the PDP does not need 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 the subjects of end entity certificates [RFC3280]. 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 PEP systems are access controlled, PEPs MUST be the subjects of end entity certificates [RFC3280]. 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 trust anchor for each authorized Certification Authority (CA) that issues certificates to supported PEPs.
When access controls are in effect at the PDP, PDP implementations MUST have a mechanism to securely acquire the trust anchor for each authorized Certification Authority (CA) that issues certificates to supported PEPs.
7.2. PDP Identity
7.2. PDP Identity
Generally, COPS/TLS requests are generated by the PEP consulting bootstrap policy information that identifies PDPs that the PEP is authorized to connect to. This policy provides the PEP with the hostname or IP address of the PDP. 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.
Generally, COPS/TLS requests are generated by the PEP consulting bootstrap policy information that identifies PDPs that the PEP is authorized to connect to. This policy provides the PEP with the hostname or IP address of the PDP. 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.
All PEP implementations MUST be able to securely acquire the trust anchor for each authorized Certification Authority (CA) that issues PDP certificates. Also, the PEPs MUST support a mechanism to securely acquire an access control list (ACL) or filter identifying the set of authorized PDPs associated with each CA. Deployments must take care to avoid circular dependencies in accessing trust anchors
All PEP implementations MUST be able to securely acquire the trust anchor for each authorized Certification Authority (CA) that issues PDP certificates. Also, the PEPs MUST support a mechanism to securely acquire an access control list (ACL) or filter identifying the set of authorized PDPs associated with each CA. Deployments must take care to avoid circular dependencies in accessing trust anchors
Walker & Kulkarni Standards Track [Page 9] RFC 4261 COPS Over TLS December 2005
Walker & Kulkarni Standards Track [Page 9] RFC 4261 COPS Over TLS December 2005
and ACLs. At a minimum, trust anchors and ACLs may be installed manually.
and ACLs. At a minimum, trust anchors and ACLs may be installed manually.
PEP deployments that participate in multiple domains, such as those on mobile platforms, MAY use different CAs and access control lists in each domain.
PEP deployments that participate in multiple domains, such as those on mobile platforms, MAY use different CAs and access control lists in each domain.
If the PDP hostname or IP address is available via the bootstrap policy, the PEP MUST check it against the PDP's identity as presented in the PDP's TLS Certificate message.
If the PDP hostname or IP address is available via the bootstrap policy, 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 iPAddress format matching the expected name of the policy server.
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 iPAddress 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 that enables it.
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 that enables it.
8. Cipher Suite Requirements
8. Cipher Suite Requirements
Implementations MUST support the TLS_RSA_WITH_3DES_EDE_CBC_SHA cipher suite. All other cipher suites are optional.
Implementations MUST support the TLS_RSA_WITH_3DES_EDE_CBC_SHA cipher suite. All other cipher suites are optional.
9. Backward Compatibility
9. Backward Compatibility
The PEP and PDP SHOULD be backward compatible with peers that have not been modified to support COPS/TLS. They SHOULD handle errors generated in response to the Integrity-TLS object.
The PEP and PDP SHOULD be backward compatible with peers that have not been modified to support COPS/TLS. They SHOULD handle errors generated in response to the Integrity-TLS object.
10. IANA Considerations
10. IANA Considerations
The IANA has added the following C-Num, C-Type combination for the Integrity-TLS object to the registry at http://www.iana.org/assignments/cops-parameters:
The IANA has added the following C-Num, C-Type combination for the Integrity-TLS object to the registry at http://www.iana.org/assignments/cops-parameters:
0x10 0x02 Message Integrity, Integrity-TLS [RFC4261]
0x10 0x02 Message Integrity, Integrity-TLS [RFC4261]
Walker & Kulkarni Standards Track [Page 10] RFC 4261 COPS Over TLS December 2005
Walker & Kulkarni Standards Track [Page 10] RFC 4261 COPS Over TLS December 2005
For Client-Type 0, the IANA has added the following Flags value for the Integrity-TLS object:
For Client-Type 0, the IANA has added the following Flags value for the Integrity-TLS object:
0x01 = StartTLS
0x01 = StartTLS
Further, for Client-Type 0, the IANA has added the following text for Error Sub-Codes:
Further, for Client-Type 0, the IANA has added the following text for Error Sub-Codes:
Error Code: 15
Error Sub-Code:
Octet 2: C-Num of the Integrity object
Octet 3: C-Type of the supported/preferred Integrity object or
Zero.
Error Code: 15 Error Sub-Code: Octet 2: C-Num of the Integrity object Octet 3: C-Type of the supported/preferred Integrity object or Zero.
Error-Code Error-SubCode Description
Octet 2 Octet 3
---------------------------------------------------
15 16 0 No security
15 16 2 Integrity-TLS supported/preferred
Error-Code Error-SubCode Description Octet 2 Octet 3 --------------------------------------------------- 15 16 0 No security 15 16 2 Integrity-TLS supported/preferred
Further values for the Flags field and the reserved field can only be assigned by IETF Consensus rule, as defined in [RFC2434].
Further values for the Flags field and the reserved field can only be assigned by IETF Consensus rule, as defined in [RFC2434].
11. Security Considerations
11. Security Considerations
A COPS PDP and PEP MUST check the results of the TLS negotiation to see whether an acceptable degree of authentication and privacy have been achieved. If the negotiation has resulted in unacceptable algorithms or key lengths, either side MAY choose to terminate the connection.
A COPS PDP and PEP MUST check the results of the TLS negotiation to see whether an acceptable degree of authentication and privacy have been achieved. If the negotiation has resulted in unacceptable algorithms or key lengths, either side MAY choose to terminate the connection.
A man-in-the-middle attack can be launched by deleting the Integrity-TLS object or altering the Client-Open or Client-Accept messages. If security is required, the PEP and PDP bootstrap policy must specify this, and PEP and PDP implementations should reject Client-Open or Client-Accept messages that fail to include an Integrity-TLS object.
A man-in-the-middle attack can be launched by deleting the Integrity-TLS object or altering the Client-Open or Client-Accept messages. If security is required, the PEP and PDP bootstrap policy must specify this, and PEP and PDP implementations should reject Client-Open or Client-Accept messages that fail to include an Integrity-TLS object.
12. Acknowledgements
12. Acknowledgements
This document freely plagiarizes and adapts Eric Rescorla's similar document [RFC2818] that specifies how HTTP runs over TLS.
This document freely plagiarizes and adapts Eric Rescorla's similar document [RFC2818] that specifies how HTTP runs over TLS.
Discussions with David Durham, Scott Hahn, and Ylian Sainte-Hillaire also lead to improvements in this document.
Discussions with David Durham, Scott Hahn, and Ylian Sainte-Hillaire also lead to improvements in this document.
The authors wish to thank Uri Blumenthal for doing a thorough security review of the document.
The authors wish to thank Uri Blumenthal for doing a thorough security review of the document.
Walker & Kulkarni Standards Track [Page 11] RFC 4261 COPS Over TLS December 2005
Walker & Kulkarni Standards Track [Page 11] RFC 4261 COPS Over TLS December 2005
13. References
13. References
13.1. Normative References
13.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[RFC2748] Durham, D., Boyle, J., Cohen, R., Herzog, S., Rajan, R.,
and A. Sastry, "The COPS (Common Open Policy Service)
Protocol", RFC 2748, January 2000.
[RFC2748] ダラム、D.、ボイル、J.、コーエン、R.、ハーツォグ、S.、Rajan、R.、およびA.Sastry、「巡査(一般的なオープンポリシーサービス)は議定書を作ります」、RFC2748、2000年1月。
[RFC2753] Yavatkar, R., Pendarakis, D., and R. Guerin, "A Framework
for Policy-based Admission Control", RFC 2753, January
2000.
[RFC2753] Yavatkar、R.、Pendarakis、D.、およびR.ゲラン、「方針ベースの入場コントロールのための枠組み」、RFC2753、2000年1月。
[RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet
X.509 Public Key Infrastructure Certificate and Certificate
Revocation List (CRL) Profile", RFC 3280, April 2002.
[RFC3280] Housley、R.、ポーク、W.、フォード、W.、および一人で生活して、「インターネットX.509公開鍵暗号基盤証明書と証明書失効リスト(CRL)は輪郭を描く」D.、RFC3280(2002年4月)。
[RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
RFC 2246, January 1999.
[RFC2246] Dierks、T.、およびC.アレン、「TLSは1999年1月にバージョン1インチ、RFC2246について議定書の中で述べます」。
13.2. Informative References
13.2. 有益な参照
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[RFC2818]レスコラ(E.、「TLSの上のHTTP」、RFC2818)は2000がそうするかもしれません。
[RFC2595] Newman, C., "Using TLS with IMAP, POP3 and ACAP", RFC 2595,
June 1999.
[RFC2595] ニューマン、C.、「IMAP、POP3、およびACAPとTLSを使用します」、RFC2595、1999年6月。
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998.
[RFC2434]Narten、T.とH.Alvestrand、「RFCsにIANA問題部に書くためのガイドライン」BCP26、RFC2434(1998年10月)。
Walker & Kulkarni Standards Track [Page 12] RFC 4261 COPS Over TLS December 2005
ウォーカーとKulkarni規格は2005年12月にTLSの上のRFC巡査4261部を追跡します[12ページ]。
Authors' Addresses
作者のアドレス
Amol Kulkarni Intel Corporation 2111 N.E. 25th Avenue Hillsboro, OR 97214 USA
アーモルKulkarniインテル社2111Avenueヒースボロー、または25番目の97214の東北米国
EMail: amol.kulkarni@intel.com
メール: amol.kulkarni@intel.com
Jesse R. Walker Intel Corporation 2111 N.E. 25th Avenue Hillsboro, OR 97214 USA
ジェシーR.ウォーカーインテル社2111Avenueヒースボロー、または25番目の97214の東北米国
EMail: jesse.walker@intel.com
メール: jesse.walker@intel.com
Walker & Kulkarni Standards Track [Page 13] RFC 4261 COPS Over TLS December 2005
ウォーカーとKulkarni規格は2005年12月にTLSの上のRFC巡査4261部を追跡します[13ページ]。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2005).
Copyright(C)インターネット協会(2005)。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Intellectual Property
知的所有権
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org.
IETFはこの規格を実行するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf ipr@ietf.org のIETFに情報を記述してください。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Walker & Kulkarni Standards Track [Page 14]
ウォーカーとKulkarni標準化過程[14ページ]
一覧
スポンサーリンク
