draft-ietf-rap-cops-tls-08.txt   draft-ietf-rap-cops-tls-09.txt 
Internet Draft Jesse Walker Internet Draft Jesse Walker
Expiration: February 2005 Amol Kulkarni, Ed. Expiration: March 2005 Amol Kulkarni, Ed.
File: draft-ietf-rap-cops-tls-08.txt Intel Corp. File: draft-ietf-rap-cops-tls-09.txt Intel Corp.
COPS Over TLS COPS Over TLS
Last Updated: August 16, 2004 Last Updated: September 24, 2004
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is subject to all provisions
all provisions of Section 10 of [RFC2026]. of section 3 of RFC 3667 [RFC3667]. By submitting this Internet-
Draft, each author represents that any applicable patent or other
IPR claims of which he or she is aware have been or will be
disclosed, and any of which he or she become aware will be
disclosed, in accordance with 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 1, line 37 skipping to change at page 1, line 41
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Conventions used in this document Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in [RFC2119]. this document are to be interpreted as described in RFC 2119
[RFC2119].
Abstract Abstract
This memo describes how to use TLS to secure COPS connections over This document describes how to use Transport Layer Security (TLS)
the Internet. to secure Common Open Policy Service (COPS) connections over the
Internet.
Please send comments on this document to the rap@ops.ietf.org This document also updates RFC 2748 by modifying the contents of
mailing list. the Client-Accept message.
Table Of Contents Table Of Contents
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 StartTLS ClientSI Object..................................4 4.1 The Security ClientSI Object..................................4
4.2 Error Codes...................................................4 4.2 Error Codes...................................................4
5 COPS/TLS Secure Connection Initiation..........................4 5 COPS/TLS Secure Connection Initiation..........................4
5.1 PDP Initiated Security Negotiation............................4 5.1 PEP Initiated Security Negotiation............................5
5.2 PEP Initiated Security Negotiation............................5 5.2 PDP Initiated Security Negotiation............................5
6 Connection Closure.............................................6 6 Connection Closure.............................................6
6.1 PEP System Behavior...........................................6 6.1 PEP System Behavior...........................................6
6.2 PDP System Behavior...........................................6 6.2 PDP System Behavior...........................................7
7 Port Number....................................................7 7 Endpoint Identification and Access Control.....................7
8 Endpoint Identification and Access Control.....................7 7.1 PDP Identity..................................................8
8.1 PDP Identity..................................................8 7.2 PEP Identity..................................................8
8.2 PEP Identity..................................................8 8 Backward Compatibility.........................................9
9 Backward Compatibility.........................................9 9 IANA Considerations.............................................9
10 IANA Considerations............................................9 10 Security Considerations........................................9
11 Security Considerations........................................9 11 References.....................................................9
12 Acknowledgements...............................................9 11.1 Normative References........................................10
13 References....................................................10 11.2 Informative References......................................10
13.1 Normative References........................................10 12 Author Addresses.............................................10
13.2 Informative References......................................10 13 IPR Disclosure Acknowledgement...............................10
14 Author Addresses.............................................10 14 Disclaimer of Validity.......................................11
15 Intellectual Property Statement..............................11 15 Copyright Statement..........................................11
16 Full Copyright Statement......................................11 16 Disclaimer...................................................11
17 Acknowledgements.............................................11
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].
1 Introduction 1 Introduction
skipping to change at page 4, line 18 skipping to change at page 4, line 18
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. COPS/TLS uses the Upward Negotiation method to secure COPS messages.
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 StartTLS ClientSI Object 4.1 The Security ClientSI Object
The StartTLS ClientSI object is used by the PDP and the PEP to start The Security ClientSI object is used by the PDP and the PEP to start
the TLS negotiation. This object can be included either in the the TLS negotiation. This object should be included only in the
ClientAccept message, or a Request message. Also, the ClientType of Client-Open or Client-Accept messages. It MUST NOT be included in
any message containing this ClientSI object MUST be 0. any other COPS message.
0 1 2 3 0 1 2 3
+----------+----------+----------+----------+ +----------+----------+----------+----------+
| Length (Octets) | C-Num=9 | C-Type=1 | | Length (Octets) | C-Num=9 | C-Type=2 |
+----------+----------+----------+----------+ +----------+----------+----------+----------+
| //////// | Flags | | //////// | Flags |
+----------+----------+----------+----------+ +----------+----------+----------+----------+
Note: //// implies the field is reserved, set to 0 and should be
ignored on receipt.
Flags: Flags: 16 bits
1 = TLS 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 Named ClientSI 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 adds to the error codes described in section 2.2.8 This section adds to the error codes described in section 2.2.8
(Error Object) of [RFC2748]. (Error Object) of [RFC2748].
Error Code: 16 = TLS Required Error Code: error-code-TBD-by-IANA = TLS Required
This error code should be used by either PEP or PDP if they require This error code should be used by either PEP or PDP to indicate a
security but the other side doesn't support it. security-related connection closure.
5 COPS/TLS Secure Connection Initiation 5 COPS/TLS Secure Connection Initiation
Security negotiation may be initiated either by the PDP or the PEP. Security negotiation may be initiated either by the PDP or the PEP.
The PDP can initiate a security negotiation either via a The PEP can initiate a negotiation via a Client-Open message, while
ClientAccept or a ClientClose message, while a PEP can initiate a a PDP can initiate a negotiation via a Client-Accept message.
negotiation via a Request message.
Once the TLS connection is established, all COPS data MUST be sent Once the TLS connection is established, all COPS data MUST be sent
as TLS "application data". as TLS "application data".
5.1 PDP Initiated Security Negotiation 5.1 PEP Initiated Security Negotiation
The PEP initially opens a TCP connection with the PDP on the
standard COPS port and sends a ClientOpen message. This ClientOpen
message MUST have a ClientType of 0.
The PDP then replies with a ClientAccept. In order to signal the PEP A PEP MAY initiate security negotiation with a PDP using the Client-
to start the TLS handshake, the PDP MUST include the StartTLS Open message. The Client-Open message MUST have a Client-Type of 0
ClientSI object in the ClientAccept message. and MUST include the Security ClientSI object.
Note that in order to carry the StartTLS ClientSI object, the Upon receiving the Client-Open message, the PDP SHOULD respond with
contents of the ClientAccept message defined in section 3.7 of a Client-Accept message containing the Security ClientSI object.
Note that in order to carry the Security ClientSI object, the
contents of the Client-Accept message defined in section 3.7 of
[RFC2748] need to change to the following: [RFC2748] need to change to the following:
<Client-Accept> ::= <Common Header> <Client-Accept> ::= <Common Header>
<KA Timer> <KA Timer>
[<ACCT Timer>] [<ACCT Timer>]
[<ClientSI>] [<ClientSI>]
[<Integrity>] [<Integrity>]
Upon receiving the ClientAccept message with the StartTLS ClientSI Upon receiving the appropriate Client-Accept message, the PEP SHOULD
object, the PEP SHOULD initiate the TLS handshake. If for any reason initiate the TLS handshake.
the PEP cannot initiate the handshake, it MUST close the connection.
The message exchange is as follows: The message exchange is as follows:
C: ClientOpen (ClientType = 0) C: Client-Open (Client-Type = 0, Security)
S: ClientAccept (ClientType = 0, StartTLS) S: Client-Accept (Client-Type = 0, Security)
<TLS handshake> <TLS handshake>
C/S: <...further messages...> C/S: <...further messages...>
Until the TLS handshake is complete the PEP MUST NOT send any Instead of sending a Client-Accept message, the PDP may choose to
messages other than ClientClose and KeepAlive. Upon receiving any close the connection if it does not wish to open a secure connection
other message, a PDP expecting a TLS negotiation MUST issue a with the PEP. It MUST include the error code error-code-TBD-by-IANA
ClientClose message with an error code of 16. in the ensuing Client-Close message.
5.2 PEP Initiated Security Negotiation A PEP expecting the Security ClientSI object in a Client-Accept
message MUST close the connection if the ClientSI object is missing.
It MUST include the error code error-code-TBD-by-IANA in the ensuing
Client-Close message.
If a PEP wishes to use TLS on an existing non-secure COPS 5.2 PDP Initiated Security Negotiation
connection, it MUST issue a Request message with a ClientType of 0.
The StartTLS ClientSI object MUST be included in the request.
In response, the PDP SHOULD send a Decision message containing the The PEP initially opens a TCP connection with the PDP on the
appropriate Command-Code (1 = Install/Accept, 2 = Remove/Reject) in standard COPS port and sends a Client-Open message. This Client-Open
the Decision Flags object. message MUST have a Client-Type of 0.
If the request is accepted, the PEP MUST start the TLS handshake. The PDP SHOULD then reply with a Client-Accept message. In order to
After the TLS handshake is complete, the PDP MUST synchronize state signal the PEP to start the TLS handshake, the PDP MUST include the
with the PEP. Security ClientSI object in the Client-Accept message.
Upon receiving the Client-Accept message with the Security ClientSI
object, the PEP SHOULD initiate the TLS handshake. If for any reason
the PEP cannot initiate the handshake, it MUST close the connection.
The message exchange is as follows: The message exchange is as follows:
<...existing COPS/TCP connection...> C: Client-Open (Client-Type = 0)
C: Request (ClientType = 0, StartTLS) S: Client-Accept (Client-Type = 0, Security)
S: Decision (ClientType = 0, Install)
<TLS handshake> <TLS handshake>
S: Synchronize C/S: <...further messages...>
If the PEP's TLS request is rejected by the PDP, the PEP MAY choose
to continue using the non-secure connection. Else, it MUST close the Before completion of the TLS handshake, the PEP MUST NOT send any
connection by sending a ClientClose message with an error code of messages other than Client-Close and Keep-Alive. Upon receiving any
16. other message, a PDP expecting a TLS negotiation MUST issue a
Client-Close message with an error code of error-code-TBD-by-IANA.
A PDP wishing to negotiate security with a PEP having a non-secure
connection MUST send a Client-Close with the error code error-code-
TBD-by-IANA and 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 TLS provides facilities to securely close its connections. Reception
of a valid closure alert assures an implementation that no further of a valid closure alert assures an implementation that no further
data will arrive on that connection. The TLS specification requires data will arrive on that connection. The TLS specification requires
TLS implementations to initiate a closure alert exchange before TLS implementations to initiate a closure alert exchange before
closing a connection. It also permits TLS implementations to close closing a connection. It also permits TLS implementations to close
connections without waiting to receive closure alerts from the peer, connections without waiting to receive closure alerts from the peer,
provided they send their own first. A connection closed in this way provided they send their own first. A connection closed in this way
skipping to change at page 7, line 10 skipping to change at page 7, line 28
Implementation note: The PDP ordinarily expects to be able to Implementation note: The PDP ordinarily expects to be able to
signal end of data by closing the connection. However, the PEP signal end of data by closing the connection. However, the PEP
may have already sent the closure alert and dropped the may have already sent the closure alert and dropped the
connection. connection.
PDP systems MUST attempt to initiate an exchange of closure alerts PDP systems MUST attempt to initiate an exchange of closure alerts
with the PEP system before closing the connection. PDP systems MAY with the PEP system before closing the connection. PDP systems MAY
close the connection after sending the closure alert, thus close the connection after sending the closure alert, thus
generating an incomplete close on the PEP side. generating an incomplete close on the PEP side.
7 Port Number 7 Endpoint Identification and Access Control
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 PDP)
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 TCP port is any
non-well-known port of the PDP's choice. This port MUST be
communicated to the COPS/TCP PDP running on the well-known COPS TCP
port. 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.
8 Endpoint Identification and Access Control
All PEP implementations of COPS/TLS MUST support an access control All PEP implementations of COPS/TLS MUST support an access control
mechanism to identify authorized PDPs. This requirement provides a mechanism to identify authorized PDPs. This requirement provides a
level of assurance that the policy arriving at the PEP is actually level of assurance that the policy arriving at the PEP is actually
valid. PEP implementations SHOULD require the use of this access valid. PEP deployments SHOULD require the use of this access control
control mechanism for operation of COPS over TLS. When access mechanism for operation of COPS over TLS. When access control is
control is enabled, the PEP implementation MUST NOT initiate enabled, the PEP implementation MUST NOT initiate COPS/TLS
COPS/TLS connections to systems not authorized as PDPs by the access connections to systems not authorized as PDPs by the access control
control mechanism. mechanism.
Similarly, PDP COPS/TLS implementations MUST support an access Similarly, PDP COPS/TLS implementations MUST support an access
control mechanism permitting them to restrict their services to control mechanism permitting them to restrict their services to
authorized PEP systems only. However, implementations MAY choose not authorized PEP systems only. However, deployments MAY choose not to
to use an access control mechanism at the PDP, as organizations use an access control mechanism at the PDP, as organizations might
might not consider the types of policy being deployed as sensitive, not consider the types of policy being deployed as sensitive, and
and therefore do not need to incur the expense of managing therefore do not need to incur the expense of managing credentials
credentials for the PEP systems. If access controls are used, for the PEP systems. If access controls are used, however, the PDP
however, the PDP implementation MUST terminate COPS/TLS connections implementation MUST terminate COPS/TLS connections from unauthorized
from unauthorized PEP systems and log an error if an auditable PEP systems and log an error if an auditable logging mechanism is
logging mechanism is present. present.
Implementations of COPS/TLS MUST use X.509 v3 certificates Implementations of COPS/TLS MUST use X.509 v3 certificates
conforming to [RFC3280] to identify PDP and PEP systems. COPS/TLS conforming to [RFC3280] to identify PDP and PEP systems. COPS/TLS
systems MUST perform certificate verification processing conforming systems MUST perform certificate verification processing conforming
to [RFC3280]. to [RFC3280].
If a subjectAltName extension of type dNSName or iPAddress is If a subjectAltName extension of type dNSName or iPAddress is
present in the PDP's certificate, it MUST be used as the PDP 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 identity. If both types are present, dNSName SHOULD be used as the
PDP identity. If neither of the types is present, the most specific PDP identity. If neither of the types is present, the most specific
skipping to change at page 8, line 13 skipping to change at page 8, line 16
used. used.
Matching is performed using the matching rules specified by Matching is performed using the matching rules specified by
[RFC3280]. If more than one identity of a given type is present in [RFC3280]. If more than one identity of a given type is present in
the certificate (e.g. more than one dNSName name in the the certificate (e.g. more than one dNSName name in the
subjectAltName certificate extension), a match in any one of the subjectAltName certificate extension), a match in any one of the
provided identities is acceptable. Generally, the COPS system uses provided identities is acceptable. Generally, the COPS system uses
the first name for matching, except as noted below in the IP the first name for matching, except as noted below in the IP
address checking requirements. address checking requirements.
8.1 PDP Identity 7.1 PDP Identity
Generally, COPS/TLS requests are generated by the PEP consulting Generally, COPS/TLS requests are generated by the PEP consulting
bootstrap policy information that identifies PDPs that the PEP is bootstrap policy information that identifies PDPs that the PEP is
authorized to connect to. This policy provides the PEP with the authorized to connect to. This policy provides the PEP with the
hostname or IP address of the PDP. How this bootstrap policy hostname or IP address of the PDP. How this bootstrap policy
information arrives at the PEP is outside the scope of this information arrives at the PEP is outside the scope of this
document. However, all PEP implementations MUST provide a mechanism document. However, all PEP implementations MUST provide a mechanism
to securely deliver or configure the bootstrap policy. to securely deliver or configure the bootstrap policy.
All PEP implementations MUST be able to securely acquire the signing All PEP implementations MUST be able to securely acquire the signing
certificates of authorized Certificate Authorities that issue PDP certificates of authorized Certificate Authorities that issue PDP
certificates. Also, the PEPs MUST support a mechanism to securely certificates. Also, the PEPs MUST support a mechanism to securely
acquire an access control list or filter identifying the CA's set of acquire an access control list or filter identifying the CA's set of
authorized PDPs. authorized PDPs.
PEP implementations that participate in multiple domains, such as PEP deployments that participate in multiple domains, such as those
those on mobile platforms, MAY use different CAs and access control on mobile platforms, MAY use different CAs and access control lists
lists in each domain. in each domain.
If the PDP hostname or IP address is available via the bootstrap If the PDP hostname or IP address is available via the bootstrap
policy, the PEP MUST check it against the PDP's identity as policy, the PEP MUST check it against the PDP's identity as
presented in the PDP's TLS Certificate message. presented in the PDP's TLS Certificate message.
In some cases the bootstrap policy will identify the authorized PDP In some cases the bootstrap policy will identify the authorized PDP
only by an IP address of the PDP system. In this case, the only by an IP address of the PDP system. In this case, the
subjectAltName MUST be present in the certificate, and it MUST subjectAltName MUST be present in the certificate, and it MUST
include an iPAdress format matching the expected name of the policy include an iPAdress format matching the expected name of the policy
server. server.
skipping to change at page 8, line 53 skipping to change at page 8, line 56
If the hostname of the PDP does not match the identity in the 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 certificate, a PEP on a user oriented system MUST either notify the
user (PEP systems MAY afford the user the opportunity to continue user (PEP systems MAY afford the user the opportunity to continue
with the connection in any case) or terminate the connection with a with the connection in any case) or terminate the connection with a
bad certificate error. PEPs on unattended systems MUST log the error bad certificate error. PEPs on unattended systems MUST log the error
to an appropriate audit log (if available) and MUST terminate the to an appropriate audit log (if available) and MUST terminate the
connection with a bad certificate error. Unattended PEP systems MAY connection with a bad certificate error. Unattended PEP systems MAY
provide a configuration setting that disables this check, but then provide a configuration setting that disables this check, but then
MUST provide a setting which enables it. MUST provide a setting which enables it.
8.2 PEP Identity 7.2 PEP Identity
When PEP systems are not access controlled, the PDP need have no 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 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 checks are neither possible nor necessary. In this case, there is no
requirement for PEP systems to register with a certificate requirement for PEP systems to register with a certificate
authority, and COPS over TLS uses one-way authentication, of the PDP authority, and COPS over TLS uses one-way authentication, of the PDP
to the PEP. to the PEP.
When PEP systems are access controlled, PEPs MUST be PKI clients in When PEP systems are access controlled, PEPs MUST be PKI clients in
the sense of [RFC3280]. In this case, COPS over TLS uses two-way the sense of [RFC3280]. In this case, COPS over TLS uses two-way
authentication, and the PDP MUST perform the same identity checks authentication, and the PDP MUST perform the same identity checks
for the PEPs as described above for the PDP. 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 signing certificates MUST have a mechanism to securely acquire the signing certificates
of the Certificate Authorities issuing certificates to any of the of the Certificate Authorities issuing certificates to any of the
PEPs they support. PEPs they support.
9 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 StartTLS ClientSI object. generated in response to the Security ClientSI object.
In case a PEP does not start the TLS handshake upon receiving the
StartTLS ClientSI object, the PDP MUST close the connection.
10 IANA Considerations 9 IANA Considerations
The IANA shall add the following Error-Code to the cops-parameters The IANA shall add the following Error-Code to the cops-parameters
document: registry located at http://www.iana.org/assignments/cops-parameters.
Error-Code: 16 Error-Code: error-code-TBD-by-IANA
Description: TLS Required Description: TLS Required
11 Security Considerations For the Named ClientSI object for Client-Type 0, the IANA shall add
the following Flags value:
0x01 = StartTLS
Further values for the Flags field and the reserved field can only
be assigned by IETF Consensus rule as defined in [RFC2434].
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.
A man-in-the-middle attack can be launched by deleting the StartTLS A man-in-the-middle attack can be launched by deleting the Security
ClientSI object from the ClientAccept or Request messages. To ClientSI object from the Client-Open or Client-Accept messages. To
prevent this, the PEP and PDP MUST use the Integrity object as prevent this, the PEP and PDP MUST use the Integrity object as
defined in [RFC2748]. defined in [RFC2748].
A downgrade attack against a PEP requesting TLS negotiation is 11 References
possible by modifying the PDP's Decision message flag to 'Remove'. 11.1 Normative References
Again, this can be avoided by using the Integrity object as defined
in [RFC2748].
12 Acknowledgements
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.
The authors wish to thank Uri Blumenthal for doing a thorough
security review of the document.
13 References
13.1 Normative References
[RFC2026] Bradner, S., "The Internet Standards Process - Revision [RFC2026] Bradner, S., "The Internet Standards Process - Revision
3", RFC 2026, October 1996 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.
[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.
13.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 [RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP
over Transport Layer Security", RFC 3207, February 2002. over Transport Layer Security", RFC 3207, February 2002.
14 Author Addresses [RFC2434] Alvestrand, H., Narten, T., "Guidelines for writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434, October
1998.
12 Author Addresses
Jesse R. Walker Jesse R. Walker
Intel Corporation Intel Corporation
2111 N.E. 25th Avenue 2111 N.E. 25th Avenue
Hillsboro, OR 97214 Hillsboro, OR 97214
USA USA
jesse.walker[at]intel.com jesse[dot]walker[at]intel[dot]com
Amol Kulkarni Amol Kulkarni
Intel Corporation Intel Corporation
JF3-206 JF3-206
2111 N.E. 25th Avenue 2111 N.E. 25th Avenue
Hillsboro, OR 97214 Hillsboro, OR 97214
USA USA
amol.kulkarni[at]intel.com amol[dot]kulkarni[at]intel[dot]com
15 Intellectual Property Statement
13 IPR Disclosure Acknowledgement
By submitting this Internet-Draft, we certify that any applicable
patent or other IPR claims of which we are aware have been
disclosed, and any of which we become aware will be disclosed, in
accordance with RFC 3668.
14 Disclaimer of Validity
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed
pertain to the implementation or use of the technology described in to pertain to the implementation or use of the technology described
this document or the extent to which any license under such rights in this document or the extent to which any license under such
might or might not be available; neither does it represent that it rights might or might not be available; nor does it represent that
has made any effort to identify any such rights. Information on the it has made any independent effort to identify any such rights.
IETF's procedures with respect to rights in standards-track and Information on the procedures with respect to rights in RFC
standards-related documentation can be found in BCP-11. Copies of documents can be found in BCP 78 and BCP 79.
claims of rights made available for publication and any assurances
of licenses to be made available, or the result of an attempt made Copies of IPR disclosures made to the IETF Secretariat and any
to obtain a general license or permission for the use of such assurances of licenses to be made available, or the result of an
proprietary rights by implementors or users of this specification attempt made to obtain a general license or permission for the use
can be obtained from the IETF Secretariat. 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.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF Executive this standard. Please address the information to the IETF at ietf-
Director. ipr@ietf.org.
The IETF has been notified of intellectual property rights claimed 15 Copyright Statement
in regard to some or all of the specification contained in this
document. For more information consult the online list of claimed
rights.
16 Full Copyright Statement Copyright (C) The Internet Society (2004). 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.
Copyright (C) The Internet Society (2004). All Rights Reserved. 16 Disclaimer
This document and translations of it may be copied and furnished to This document and the information contained herein are provided on
others, and derivative works that comment on or otherwise explain it an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
or assist in its implementation may be prepared, copied, published REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
and distributed, in whole or in part, without restriction of any INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR
kind, provided that the above copyright notice and this paragraph IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
are included on all such copies and derivative works. However, this THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
document itself may not be modified in any way, such as by removing WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
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 must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be 17 Acknowledgements
revoked by the Internet Society or its successors or assignees.
This document and the information contained herein is provided on an This document freely plagiarizes and adapts Eric Rescorla's similar
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING document [RFC2818] that specifies how HTTP runs over TLS.
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING Discussions with David Durham, Scott Hahn and Ylian Sainte-Hillaire
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION also lead to improvements in this document.
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. The authors wish to thank Uri Blumenthal for doing a thorough
security review of the document.
Funding for the RFC Editor function is currently provided by the
Internet Society.
 End of changes. 

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