draft-ietf-rap-cops-tls-10.txt   draft-ietf-rap-cops-tls-11.txt 
Internet Draft Jesse Walker Internet Draft Jesse Walker
Expiration: June 2005 Amol Kulkarni, Ed. Expiration: August 2005 Amol Kulkarni, Ed.
File: draft-ietf-rap-cops-tls-10.txt Intel Corp. File: draft-ietf-rap-cops-tls-11.txt Intel Corp.
COPS Over TLS COPS Over TLS
Last Updated: December 1, 2004 Last Updated: February 5, 2004
Status of this Memo Status of this Memo
This document is an Internet-Draft and is subject to all provisions This document is an Internet-Draft and is subject to all provisions
of section 3 of RFC 3667 [RFC3667]. By submitting this Internet- of section 3 of RFC 3667. By submitting this Internet-Draft, each
Draft, each author represents that any applicable patent or other author represents that any applicable patent or other IPR claims of
IPR claims of which he or she is aware have been or will be which he or she is aware have been or will be disclosed, and any of
disclosed, and any of which he or she become aware will be which he or she become aware will be disclosed, in accordance with
disclosed, in accordance with RFC 3668. RFC 3668.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-Drafts documents at any time. It is inappropriate to use Internet-Drafts
as reference material or to cite them other than as "work in as reference material or to cite them other than as "work in
skipping to change at page 2, line 17 skipping to change at page 2, line 17
Glossary..........................................................3 Glossary..........................................................3
1 Introduction...................................................3 1 Introduction...................................................3
2 COPS Over TLS..................................................3 2 COPS Over TLS..................................................3
3 Separate Ports versus Upward Negotiation.......................3 3 Separate Ports versus Upward Negotiation.......................3
4 COPS/TLS Objects and Error codes...............................4 4 COPS/TLS Objects and Error codes...............................4
4.1 The TLS Message Integrity Object (Integrity-TLS)..............4 4.1 The TLS Message Integrity Object (Integrity-TLS)..............4
4.2 Error Codes...................................................4 4.2 Error Codes...................................................4
5 COPS/TLS Secure Connection Initiation..........................5 5 COPS/TLS Secure Connection Initiation..........................5
5.1 PEP Initiated Security Negotiation............................5 5.1 PEP Initiated Security Negotiation............................5
5.2 PDP Initiated Security Negotiation............................6 5.2 PDP Initiated Security Negotiation............................6
6 Connection Closure.............................................6 6 Connection Closure.............................................7
6.1 PEP System Behavior...........................................7 6.1 PEP System Behavior...........................................7
6.2 PDP System Behavior...........................................7 6.2 PDP System Behavior...........................................7
7 Endpoint Identification and Access Control.....................7 7 Endpoint Identification and Access Control.....................8
7.1 PDP Identity..................................................8 7.1 PDP Identity..................................................8
7.2 PEP Identity..................................................9 7.2 PEP Identity..................................................9
8 Backward Compatibility.........................................9 8 Backward Compatibility.........................................9
9 IANA Considerations.............................................9 9 IANA Considerations............................................10
10 Security Considerations.......................................10 10 Security Considerations.......................................10
11 References....................................................10 11 References....................................................10
11.1 Normative References........................................10 11.1 Normative References........................................10
11.2 Informative References......................................10 11.2 Informative References......................................11
12 Author Addresses.............................................11 12 Author Addresses.............................................11
13 IPR Disclosure Acknowledgement...............................11 13 IPR Disclosure Acknowledgement...............................11
14 Disclaimer of Validity.......................................11 14 Disclaimer of Validity.......................................11
15 Copyright Statement..........................................11 15 Copyright Statement..........................................12
16 Disclaimer...................................................12 16 Disclaimer...................................................12
17 Acknowledgements.............................................12 17 Acknowledgements.............................................12
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 PDP - Policy Decision Point. Also referred to as the Policy
Server. See [RFC2753]. Server. See [RFC2753].
PEP - Policy Enforcement Point. Also referred to as the Policy PEP - Policy Enforcement Point. Also referred to as the Policy
Client. See [RFC2753]. Client. See [RFC2753].
skipping to change at page 4, line 11 skipping to change at page 4, line 11
The disadvantage, however, is that it doesn't scale well, with a new The disadvantage, however, is that it doesn't scale well, with a new
port required for each secure implementation. More problems with port required for each secure implementation. More problems with
this approach have been listed in [RFC2595]. this approach have been listed in [RFC2595].
The second method is known as 'Upward Negotiation'. In this method, The second method is known as 'Upward Negotiation'. In this method,
the secure and insecure versions of the protocol run on the same the secure and insecure versions of the protocol run on the same
port. The client connects to the server, both discover each others' port. The client connects to the server, both discover each others'
capabilities, and start security negotiations if desired. This capabilities, and start security negotiations if desired. This
method usually requires some changes to the protocol being secured. method usually requires some changes to the protocol being secured.
COPS/TLS uses the Upward Negotiation method to secure COPS messages. 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 This section describes the COPS objects and error codes needed to
support COPS/TLS. 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 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- TLS negotiation. This object should be included only in the Client-
skipping to change at page 5, line 50 skipping to change at page 5, line 52
Note that in order to carry the Integrity-TLS object, the contents Note that in order to carry the Integrity-TLS object, the contents
of the Client-Accept message defined in section 3.7 of [RFC2748] of the Client-Accept message defined in section 3.7 of [RFC2748]
need not change, other than the C-Type of the integrity object need not change, other than the C-Type of the integrity object
contained there-in should now be C-Type=2. For Example: contained there-in should now be C-Type=2. For Example:
<Client-Accept> ::= <Common Header> <Client-Accept> ::= <Common Header>
<KA Timer> <KA Timer>
[<ACCT Timer>] [<ACCT Timer>]
[<Integrity (C-Num=16, C-Type=2)>] [<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.
Upon receiving the appropriate Client-Accept message, the PEP SHOULD Upon receiving the appropriate Client-Accept message, the PEP SHOULD
initiate the TLS handshake. initiate the TLS handshake.
The message exchange is as follows: The message exchange is as follows:
C: Client-Open (Client-Type = 0, Integrity-TLS) C: Client-Open (Client-Type = 0, Integrity-TLS)
S: Client-Accept (Client-Type = 0, Integrity-TLS) S: Client-Accept (Client-Type = 0, Integrity-TLS)
<TLS handshake> <TLS handshake>
C/S: <...further messages...> C/S: <...further messages...>
In case the PDP does not wish to open a secure connection with the In case the PDP does not wish to open a secure connection with the
skipping to change at page 7, line 30 skipping to change at page 7, line 37
examine the COPS data itself (specifically the Message header) to examine the COPS data itself (specifically the Message header) to
determine whether truncation occurred. determine whether truncation occurred.
6.1 PEP System Behavior 6.1 PEP System Behavior
PEP implementations MUST treat premature closes as errors and any PEP implementations MUST treat premature closes as errors and any
data received as potentially truncated. The COPS protocol allows the data received as potentially truncated. The COPS protocol allows the
PEP system to find out whether truncation took place. A PEP system PEP system to find out whether truncation took place. A PEP system
detecting an incomplete close SHOULD recover gracefully. detecting an incomplete close SHOULD recover gracefully.
PEP systems MUST send a closure alert before closing the connection. PEP systems SHOULD send a closure alert before closing the
PEPs unprepared to receive any more data MAY choose not to wait for connection. PEPs unprepared to receive any more data MAY choose not
the PDP system's closure alert and simply close the connection, thus to wait for the PDP system's closure alert and simply close the
generating an incomplete close on the PDP side. 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 COPS permits a PEP to close the connection at any time, and requires
PDPs to recover gracefully. In particular, PDPs SHOULD be prepared PDPs to recover gracefully. In particular, PDPs SHOULD be prepared
to receive an incomplete close from the PEP, since a PEP often shuts to receive an incomplete close from the PEP, since a PEP often shuts
down for operational reasons unrelated to the transfer of policy down for operational reasons unrelated to the transfer of policy
information between the PEP and PDP. information between the PEP and PDP.
Implementation note: The PDP ordinarily expects to be able to Implementation note: The PDP ordinarily expects to be able to
skipping to change at page 9, line 49 skipping to change at page 10, line 4
of end entity certificates [RFC3280]. In this case, COPS over TLS of end entity certificates [RFC3280]. In this case, COPS over TLS
uses two-way authentication, and the PDP MUST perform the same uses two-way authentication, and the PDP MUST perform the same
identity checks for the PEPs as described above for the PDP. identity checks for the PEPs as described above for the PDP.
When access controls are in effect at the PDP, PDP implementations When access controls are in effect at the PDP, PDP implementations
MUST have a mechanism to securely acquire the trust anchor for each MUST have a mechanism to securely acquire the trust anchor for each
authorized Certification Authority (CA) that issues certificates to authorized Certification Authority (CA) that issues certificates to
supported PEPs. supported PEPs.
8 Backward Compatibility 8 Backward Compatibility
The PEP and PDP SHOULD be backward compatible with peers that have The PEP and PDP SHOULD be backward compatible with peers that have
not been modified to support COPS/TLS. They SHOULD handle errors not been modified to support COPS/TLS. They SHOULD handle errors
generated in response to the Integrity-TLS object. generated in response to the Integrity-TLS object.
9 IANA Considerations 9 IANA Considerations
For the Integrity-TLS object for Client-Type 0, the IANA shall add
the following Flags value: The IANA shall add 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 [RFCxxxx]
For Client-Type 0, the IANA shall add the following Flags value for
the Integrity-TLS object:
0x01 = StartTLS 0x01 = StartTLS
Further, for Client-Type 0, the IANA shall add 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 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 Further values for the Flags field and the reserved field can only
be assigned by IETF Consensus rule as defined in [RFC2434]. be assigned by IETF Consensus rule as defined in [RFC2434].
10 Security Considerations 10 Security Considerations
A COPS PDP and PEP MUST check the results of the TLS negotiation to A COPS PDP and PEP MUST check the results of the TLS negotiation to
see whether an acceptable degree of authentication and privacy have see whether an acceptable degree of authentication and privacy have
been achieved. If the negotiation has resulted in unacceptable been achieved. If the negotiation has resulted in unacceptable
algorithms or key lengths, either side MAY choose to terminate the algorithms or key lengths, either side MAY choose to terminate the
connection. connection.
skipping to change at page 10, line 29 skipping to change at page 10, line 54
A man-in-the-middle attack can be launched by deleting the A man-in-the-middle attack can be launched by deleting the
Integrity-TLS object or altering the Client-Open or Client-Accept Integrity-TLS object or altering the Client-Open or Client-Accept
messages. If security is required, the PEP and PDP bootstrap policy messages. If security is required, the PEP and PDP bootstrap policy
must specify this, and PEP and PDP implementations should reject must specify this, and PEP and PDP implementations should reject
Client-Open or Client-Accept messages that fail to include an Client-Open or Client-Accept messages that fail to include an
Integrity-TLS object. Integrity-TLS object.
11 References 11 References
11.1 Normative References 11.1 Normative References
[RFC2026] Bradner, S., "The Internet Standards Process - Revision
3", RFC 2026, October 1996
[RFC2119] Bradner, S., "Key Words for use in RFCs to indicate [RFC2119] Bradner, S., "Key Words for use in RFCs to indicate
Requirement Levels", RFC 2119, March 1997. Requirement Levels", RFC 2119, March 1997.
[RFC2748] Durham, D., Boyle, J., Cohen, R., Herzog, R., Rajan, [RFC2748] Durham, D., Boyle, J., Cohen, R., Herzog, R., Rajan,
R., Sastry, A., "The COPS (Common Open Policy Service) Protocol", R., Sastry, A., "The COPS (Common Open Policy Service) Protocol",
RFC 2748, January 2000. RFC 2748, January 2000.
[RFC2753] Yavatkar, R., Pendarakis, D., Guerin, R., "A Framework
for Policy-based Admission Control", RFC 2753, January 2000.
[RFC3280] Housley, R., Ford, W., Polk, W., Solo, D., "Internet [RFC3280] Housley, R., Ford, W., Polk, W., Solo, D., "Internet
X.509 Public Key Infrastructure Certificate and Certificate X.509 Public Key Infrastructure Certificate and Certificate
Revocation List (CRL) Profile ", RFC 3280, April 2002. Revocation List (CRL) Profile ", RFC 3280, April 2002.
[RFC2246] Dierks, T., Allen, C., "The TLS Protocol", RFC 2246, [RFC2246] Dierks, T., Allen, C., "The TLS Protocol", RFC 2246,
January 1999. January 1999.
11.2 Informative References 11.2 Informative References
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[RFC2595] Newman, C., "Using TLS with IMAP, POP3 and ACAP", RFC [RFC2595] Newman, C., "Using TLS with IMAP, POP3 and ACAP", RFC
2595, June 1999. 2595, June 1999.
[RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP
over Transport Layer Security", RFC 3207, February 2002.
[RFC2434] Alvestrand, H., Narten, T., "Guidelines for writing an [RFC2434] Alvestrand, H., Narten, T., "Guidelines for writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434, October IANA Considerations Section in RFCs", BCP 26, RFC 2434, October
1998. 1998.
12 Author Addresses 12 Author Addresses
Amol Kulkarni Amol Kulkarni
Intel Corporation Intel Corporation
2111 N.E. 25th Avenue 2111 N.E. 25th Avenue
Hillsboro, OR 97214 Hillsboro, OR 97214
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/