draft-ietf-rap-cops-tls-06.txt   draft-ietf-rap-cops-tls-07.txt 
Internet Draft Jesse Walker Internet Draft Jesse Walker
Expiration: November 2003 Amol Kulkarni Expiration: May 2004 Amol Kulkarni, Ed.
File: draft-ietf-rap-cops-tls-06.txt Intel Corp. File: draft-ietf-rap-cops-tls-07.txt Intel Corp.
COPS Over TLS COPS Over TLS
Last Updated: May 23, 2003 Last Updated: November 24, 2003
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 in full conformance with
all provisions of Section 10 of [RFC2026]. all provisions of Section 10 of [RFC2026].
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.
skipping to change at page 2, line 6 skipping to change at page 2, line 6
Abstract Abstract
This memo describes how to use TLS to secure COPS connections over This memo describes how to use TLS to secure COPS connections over
the Internet. the Internet.
Please send comments on this document to the rap@ops.ietf.org Please send comments on this document to the rap@ops.ietf.org
mailing list. mailing list.
Table Of Contents Table Of Contents
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
3.1 The COPS/TLS approach.........................................4 3.1 The COPS/TLS approach.........................................4
3.2.1 The ClientSI object format..................................4 3.2.1 The ClientSI object format..................................5
3.2.2 Error Codes and Sub-Codes...................................5 3.2.2 Error Codes and Sub-Codes...................................5
4 Usage Scenarios................................................5 4 Usage Scenarios.................................................6
4.1 Security Mandatory on both, Client and Server.................6 4.1 Security Mandatory on both, Client and Server.................6
4.2 Security Mandatory on Client and Optional on Server...........6 4.2 Security Mandatory on Client and Optional on Server...........7
4.3 Security Optional on Client and Mandatory on Server...........6 4.3 Security Optional on Client and Mandatory on Server...........7
4.4 Security Optional on both, Client and Server..................6 4.4 Security Optional on both, Client and Server..................7
4.5 Security Mandatory on Client but not supported by Server......6 4.5 Security Mandatory on Client but not supported by Server......7
4.6 Security Optional on Client but not supported by Server.......6 4.6 Security Optional on Client but not supported by Server.......7
4.7 Security Mandatory on Server but not supported by Client......6 4.7 Security Mandatory on Server but not supported by Client......7
4.8 Security Optional on Server but not supported by Client.......6 4.8 Security Optional on Server but not supported by Client.......7
5 Secure Connection Initiation...................................7 5 Secure Connection Initiation....................................7
6 Connection Closure.............................................7 6 Connection Closure..............................................8
6.1. PEP System Behavior.........................................7 6.1. PEP System Behavior.........................................8
6.2. PDP System Behavior.........................................8 6.2. PDP System Behavior.........................................9
7 Port Number....................................................8 7 Port Number.....................................................9
8 Endpoint Identification and Access Control.....................8 8 Endpoint Identification and Access Control.....................9
8.1 PDP Identity.................................................9 8.1 PDP Identity................................................10
8.2 PEP Identity................................................10 8.2 PEP Identity................................................11
9 Other Considerations..........................................10 9 Other Considerations...........................................11
9.1 Backward Compatibility.......................................10 9.1 Backward Compatibility.......................................11
9.2 IANA Considerations..........................................10 9.2 IANA Considerations..........................................11
10 Security Considerations......................................10 10 Security Considerations......................................11
11 Acknowledgements.............................................10 11 Acknowledgements.............................................11
12 References....................................................10 12 References....................................................12
12.1 Normative References........................................10 12.1 Normative References........................................12
12.2 Informative References......................................11 12.2 Informative References......................................12
13 Author Addresses..............................................11 13 Author Addresses.............................................12
Glossary
COPS - Common Open Policy Service. See [RFC2748].
COPS/TCP - A plain-vanilla implementation of COPS.
COPS/TLS - A secure implementation of COPS using TLS.
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].
1 Introduction 1 Introduction
COPS [RFC2748] was designed to distribute clear-text policy COPS [RFC2748] was designed to distribute clear-text policy
information from a centralized Policy Decision Point (PDP) to a set information from a centralized Policy Decision Point (PDP) to a set
of Policy Enforcement Points (PEP) in the Internet. COPS provides of Policy Enforcement Points (PEP) in the Internet. COPS provides
its own security mechanisms to protect the per-hop integrity of the its own security mechanisms to protect the per-hop integrity of the
deployed policy. However, the use of COPS for sensitive applications deployed policy. However, the use of COPS for sensitive applications
such as some types of security policy distribution requires such as some types of security policy distribution requires
additional security measures, such as data privacy. This is because additional security measures, such as data privacy. This is because
some organizations find it necessary to hide some or all of their some organizations find it necessary to hide some or all of their
skipping to change at page 4, line 24 skipping to change at page 4, line 34
well-known port of its choice. The standard COPS server running over well-known port of its choice. The standard COPS server running over
TCP MUST know the TCP port on which COPS/TLS is running. How this is TCP MUST know the TCP port on which COPS/TLS is running. How this is
achieved is outside the scope of this document. achieved is outside the scope of this document.
The system acting as the PEP also acts as the TLS client. It needs The system acting as the PEP also acts as the TLS client. It needs
to first connect to the COPS/TCP server, from where it can be to first connect to the COPS/TCP server, from where it can be
redirected to the COPS/TLS server. redirected to the COPS/TLS server.
During the initial negotiation with the COPS/TCP server, the Message During the initial negotiation with the COPS/TCP server, the Message
Integrity Object MUST be used to authenticate the validity of the Integrity Object MUST be used to authenticate the validity of the
COPS messages. The use of the integrity object is described in COPS messages. As specified in [RFC2748], the integrity object
[RFC2748]. How the keys indicated by the Integrity Object are shared contains a sequence number, a Key Id and a message digest. The
between the Client and Server is outside the scope of this document. sequence number is used to foil replay attacks while the Key Id
identifies a secret key shared between the client and the server.
COPS uses the HMAC-MD5-96 algorithm to generate a digest of the
entire COPS message, up to and including the sequence number and Key
Id.
The specifics of key distribution and maintenance are outside the
scope of this document.
3.2 Object Format and Error Codes 3.2 Object Format and Error Codes
This section describes the ClientSI object sent in the ClientOpen This section describes the ClientSI object sent in the ClientOpen
message and the error codes the server returns. message and the error codes the server returns.
3.2.1 The ClientSI object format 3.2.1 The ClientSI object format
0 1 2 3 0 1 2 3
+----------+----------+----------+----------+ +----------+----------+----------+----------+
| Length (Octets) | C-Num=9 | C-Type=2 | | Length (Octets) | C-Num=9 | C-Type=1 |
+----------+----------+----------+----------+ +----------+----------+----------+----------+
| Protocol | Flags | | Protocol | Flags |
+----------+----------+----------+----------+ +----------+----------+----------+----------+
| : : : | | : : : |
// : : : // // : : : //
+----------+----------+----------+----------+ +----------+----------+----------+----------+
| Protocol | Flags | | Protocol | Flags |
+----------+----------+----------+----------+ +----------+----------+----------+----------+
Protocol: Protocol:
skipping to change at page 5, line 4 skipping to change at page 5, line 25
+----------+----------+----------+----------+ +----------+----------+----------+----------+
| Protocol | Flags | | Protocol | Flags |
+----------+----------+----------+----------+ +----------+----------+----------+----------+
Protocol: Protocol:
1 = TLS 1 = TLS
Flags: Flags:
0 = Protocol Support Optional 0 = Protocol Support Optional
1 = Protocol Support Required 1 = Protocol Support Required
This ClientSI object MUST be included with the ClientOpen message This ClientSI object MUST be included with the ClientOpen message
(Client Type = 0) when the client supports security. For each (Client Type = 0) when the client supports security. For each
supported protocol, there MUST be a 32 bit Protocol+Flags pair supported protocol, there MUST be a 32 bit Protocol+Flags pair
appended to the object. At present, only one protocol (TLS) is appended to the object. At present, only one protocol (TLS) is
described. However, the ClientSI object definition is general enough described. However, the ClientSI object definition is general enough
to allow addition of new protocols in the future. to allow addition of new protocols in the future.
If multiple protocols are supported by the client, it MUST ensure If multiple protocols are supported by the client, it MUST ensure
that no more than one has the 'Protocol Support Required' flag set. that no more than one has the 'Protocol Support Required' flag set.
Note that it is also valid to mark all protocols as optional. Note that it is also valid to mark all protocols as optional. This
is used by the client to notify the server that a secure connection
is not mandatory.
3.2.2 Error Codes and Sub-Codes 3.2.2 Error Codes and Sub-Codes
This section adds to, and modifies, the error codes described in This section adds to, and modifies, the error codes described in
section 2.2.8 (Error Object) of [RFC2748]. section 2.2.8 (Error Object) of [RFC2748].
Error Code: 12 = Redirect to Preferred Server: Error Code: 12 = Redirect to Preferred Server:
Sub-code: Sub-code:
0 = Regular redirect (no security necessary) 0 = Regular redirect (no security necessary)
1 = Use TLS 1 = Use TLS
skipping to change at page 5, line 40 skipping to change at page 6, line 14
Error Code 17 SHOULD be used by either Client or Server if they Error Code 17 SHOULD be used by either Client or Server if they
require security but the other side doesn't support it. require security but the other side doesn't support it.
4 Usage Scenarios 4 Usage Scenarios
When the client needs to open a secure connection with the server, When the client needs to open a secure connection with the server,
it SHOULD first connect to the non-secure port, and send a Client it SHOULD first connect to the non-secure port, and send a Client
Open message with a ClientType=0. Open message with a ClientType=0.
The policies implemented on the client dictate whether security is 'Bootstrap' policies implemented on the client dictate whether
mandatory or optional. security is mandatory or optional.
If the policies specify that security is mandatory, the above- If the policies specify that security is mandatory, the above-
mentioned ClientSI object MUST be included in the Client Open mentioned ClientSI object MUST be included in the Client Open
message. This object MUST list one protocol as required by setting message. This object MUST list one protocol as Required by setting
the corresponding flag to 1. the corresponding flag to 1.
If the policies do not explicitly specify that a secure connection If the policies do not explicitly specify that a secure connection
is required, the client SHOULD include the ClientSI object, listing is required, the client SHOULD include the ClientSI object, listing
protocol support as optional. protocol support as Optional.
Note that if the client's policies specifically prohibit a secure Note that if the client's policies specifically prohibit a secure
connection, it MAY attempt to establish a non-secure connection. connection, it MAY attempt to establish an insecure connection.
Based on the client's policies and the server's policy requirements Based on the client's policies and the server's policy requirements
for the client, the following scenarios occur: for the client, a number of usage scenarios are possible. The figure
below shows the type of connections established for the scenarios.
The sections following the figure explain the various scenarios in
greater detail.
+---------+------------+------------+-------------+
|\SERVER | | | |
|C\ | | | Security |
|L \ | Security | Security | Not |
|I \ | Mandatory | Optional | Supported |
|E \ | | | |
|N \ | | | |
|T \ | | | |
+---------+------------+------------+-------------+
|Mandatory| Secure | Secure | Disconnect |
+---------+------------+------------+-------------+
|Optional | Secure | Secure / | Insecure |
| | | Insecure | |
+---------+------------+------------+-------------+
|Not | | | |
|Supported| Disconnect | Insecure | Insecure |
+---------+------------+------------+-------------+
4.1 Security Mandatory on both, Client and Server 4.1 Security Mandatory on both, Client and Server
The server MUST send a ClientClose message with a Redirect object, The server MUST send a ClientClose message with a Redirect object,
redirecting the client to the COPS/TLS secure port. Additionally, redirecting the client to the COPS/TLS secure port. Additionally,
the error object included in the ClientClose message MUST have the the error object included in the ClientClose message MUST have the
error code = 12 and sub code = 1. error code = 12 and sub code = 1.
4.2 Security Mandatory on Client and Optional on Server 4.2 Security Mandatory on Client and Optional on Server
skipping to change at page 7, line 17 skipping to change at page 8, line 12
Once the PEP receives a redirect from the COPS/TCP server, it Once the PEP receives a redirect from the COPS/TCP server, it
initiates a connection to the PDP to the secure COPS port. When this initiates a connection to the PDP to the secure COPS port. When this
succeeds, the PEP system sends the TLS ClientHello to begin the TLS succeeds, the PEP system sends the TLS ClientHello to begin the TLS
handshake. When the TLS handshake completes, the PEP MAY initiate handshake. When the TLS handshake completes, the PEP MAY initiate
the first COPS message. All COPS data MUST be sent as TLS the first COPS message. All COPS data MUST be sent as TLS
"application data". Normal COPS behavior follows. "application data". Normal COPS behavior follows.
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. The access control mechanism implemented is outside the scope valid. PEP implementations SHOULD require the use of this access
of this document. PEP implementations SHOULD require the use of this control mechanism for operation of COPS over TLS. When access
access control mechanism for operation of COPS over TLS. When access
control is enabled, the PEP implementation MUST NOT initiate control is enabled, the PEP implementation MUST NOT initiate
COPS/TLS connections to systems not authorized as PDPs by the access COPS/TLS connections to systems not authorized as PDPs by the access
control mechanism. control 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 MUST NOT authorized PEP systems only. However, implementations MAY choose not
require the use of an access control mechanism at the PDP, as to use an access control mechanism at the PDP, as organizations
organizations might not consider the types of policy being deployed might not consider the types of policy being deployed as sensitive,
as sensitive, and therefore do not need to incur the expense of and therefore do not need to incur the expense of managing
managing credentials for the PEP systems. If access controls are credentials for the PEP systems. If access controls are used,
used, however, the PDP implementation MUST terminate COPS/TLS however, the PDP implementation MUST terminate COPS/TLS connections
connections from unauthorized PEP systems and log an error if an from unauthorized PEP systems and log an error if an auditable
auditable logging mechanism is present. logging mechanism is present.
Section 8 provides more details on access control.
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 8, line 51 skipping to change at page 9, line 49
COPS TCP port. The PEP may use any TCP port. This does not preclude 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 COPS/TLS from running over another transport. TLS only presumes a
reliable connection-oriented data stream. reliable connection-oriented data stream.
8 Endpoint Identification and Access Control 8 Endpoint Identification and Access Control
Implementations of COPS/TLS MUST use X.509 v3 certificates Implementations of COPS/TLS MUST use X.509 v3 certificates
conforming to [RFC2459] to identify PDP and PEP systems. COPS/TLS conforming to [RFC2459] to identify PDP and PEP systems. COPS/TLS
systems MUST perform certificate verification processing conforming systems MUST perform certificate verification processing conforming
to [RFC2459]. In case the Certificate Authority cannot be accessed, to [RFC2459]. In case the Certificate Authority cannot be accessed,
communication MAY revert to insecure. the COPS/TLS systems MAY use a Web of Trust to verify the identity,
or the communication MAY revert to insecure.
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, that MUST be used as the PDP present in the PDP's certificate, it MUST be used as the PDP
identity. Otherwise, the most specific Common Name field in the identity. Otherwise, the most specific Common Name field in the
Subject field of the certificate MUST be used. Subject field of the certificate MUST be used.
Matching is performed using the matching rules specified by Matching is performed using the matching rules specified by
[RFC2459]. If more than one identity of a given type is present in [RFC2459]. If more than one identity of a given type is present in
the certificate (e.g. more than one dNSName name, a match in any one the certificate (e.g. more than one dNSName name, a match in any one
of the set is considered acceptable.), the COPS system uses the of the set is considered acceptable), the COPS system uses the first
first name to match, except as noted below in the IP address name to match, except as noted below in the IP address checking
checking requirements. Names may contain the wildcard character * requirements. Names may contain the wildcard character * which is
which is considered to match any single domain name component or considered to match any single domain name component or component
component fragment. For example, *.a.com matches foo.a.com but not fragment. For example, *.a.com matches foo.a.com but not
bar.foo.a.com. f*.com matches foo.com but not foo.bar.com. bar.foo.a.com. f*.com matches foo.com but not foo.bar.com.
8.1 PDP Identity 8.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 identifying authorized PDPs. As a bootstrap policy information that identifies PDPs that the PEP is
consequence, the hostname or IP address for the PDP is known to the authorized to connect to. This policy provides the PEP with the
PEP. How this bootstrap policy information arrives at the PEP is hostname or IP address of the PDP. How this bootstrap policy
outside the scope of this document. However, all PEP implementations information arrives at the PEP is outside the scope of this
MUST provide a mechanism to securely deliver or configure the document. However, all PEP implementations MUST provide a mechanism
bootstrap policy. In particular, all PEP implementations MUST to securely deliver or configure the bootstrap policy.
support a mechanism to securely acquire the signing certificate of
the authorized certificate authorities issuing PDP certificates, and
MUST support a mechanism to securely acquire an access control list
or filter identifying its set of authorized PDPs.
PEP implementations that participate in multiple domains, such as
those on mobile platforms, MAY use different certificate authorities
and access control lists in each domain.
Organizations may choose to deliver some or all of the bootstrap Organizations MAY choose to deliver some or all of the bootstrap
policy configuration from an untrusted source, such as DHCP. In this policy configuration from an untrusted source, such as DHCP. In this
circumstance, COPS over TLS provides no protection from attack when circumstance, COPS over TLS provides no protection from attack when
this untrusted source is compromised. this untrusted source is compromised.
If the PDP hostname or IP address is available via the access All PEP implementations MUST be able to securely acquire the signing
control mechanism, the PEP MUST check it against the PDP's identity certificates of authorized Certificate Authorities that issue PDP
as presented in the PDP's TLS Certificate message. certificates. Also, the PEPs MUST support a mechanism to securely
acquire an access control list or filter identifying the CA's set of
authorized PDPs.
PEP implementations 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.
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.
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 connection with a bad certificate error. Unattended PEP systems MAY
MAY provide a configuration setting that disables this check, but provide a configuration setting that disables this check, but then
then MUST provide a setting which enables it. MUST provide a setting which enables it.
8.2 PEP Identity 8.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 [RFC2459]. In this case, COPS over TLS uses two-way the sense of [RFC2459]. 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 Other Considerations 9 Other Considerations
9.1 Backward Compatibility 9.1 Backward Compatibility
The client and server SHOULD be backward compatible with peers that The client and server SHOULD be backward compatible with peers that
do not support security. A client SHOULD be able to handle errors have not been modified to support COPS/TLS.
generated by a server which does not understand the ClientSI object
mentioned above. Similarly, if a server receives a ClientOpen for A client SHOULD be able to handle errors generated by a COPS/TCP
server which does not understand the ClientSI object mentioned
above. Similarly, if a COPS/TCP server receives a ClientOpen for
Client type=0, which does not contain the ClientSI object, it SHOULD Client type=0, which does not contain the ClientSI object, it SHOULD
assume that the client wishes to open a non-secure connection and assume that the client wishes to open a non-secure connection and
proceed accordingly. proceed accordingly.
9.2 IANA Considerations 9.2 IANA Considerations
This draft defines some new error codes and sub codes which require This draft defines some new error codes and sub codes which require
IANA approval. Section 3.2.2 has more details on these codes. IANA approval. Section 3.2.2 has more details on these codes.
10 Security Considerations 10 Security Considerations
This entire document concerns security. This entire document concerns security.
11 Acknowledgements 11 Acknowledgements
This document freely plagiarizes and adapts Eric Rescorla's similar This document freely plagiarizes and adapts Eric Rescorla's similar
document [RFC2818] that specifies how HTTP runs over TLS. document [RFC2818] that specifies how HTTP runs over TLS.
Discussions with David Durham, Scott Hahn and Ylian Sainte-Hillaire Discussions with David Durham, Scott Hahn and Ylian Sainte-Hillaire
also lead to improvements in this document. also lead to improvements in this document.
The authors wish to thank Uri Blumenthal for doing a thorough
security review of the document.
12 References 12 References
12.1 Normative References 12.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 200. RFC 2748, January 2000.
[RFC2459] Housley, R., Ford, W., Polk, W., Solo, D., "Internet [RFC2459] Housley, R., Ford, W., Polk, W., Solo, D., "Internet
Public Key Infrastructure: Part I: X.509 Certificate and CRL Public Key Infrastructure: Part I: X.509 Certificate and CRL
Profile", RFC 2459, January 1999. Profile", RFC 2459, January 1999.
[RFC2246] Dierks, T., Allen, C., "The TLS Protocol", RFC 2246, [RFC2246] Dierks, T., Allen, C., "The TLS Protocol", RFC 2246,
January 1999. January 1999.
12.2 Informative References 12.2 Informative References
 End of changes. 

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