draft-ietf-rap-cops-tls-09.txt   draft-ietf-rap-cops-tls-10.txt 
Internet Draft Jesse Walker Internet Draft Jesse Walker
Expiration: March 2005 Amol Kulkarni, Ed. Expiration: June 2005 Amol Kulkarni, Ed.
File: draft-ietf-rap-cops-tls-09.txt Intel Corp. File: draft-ietf-rap-cops-tls-10.txt Intel Corp.
COPS Over TLS COPS Over TLS
Last Updated: September 24, 2004 Last Updated: December 1, 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 [RFC3667]. By submitting this Internet-
Draft, each author represents that any applicable patent or other Draft, each author represents that any applicable patent or other
IPR claims of which he or she is aware have been or will be 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, and any of which he or she become aware will be
disclosed, in accordance with RFC 3668. disclosed, in accordance with RFC 3668.
skipping to change at page 2, line 12 skipping to change at page 2, line 12
This document also updates RFC 2748 by modifying the contents of This document also updates RFC 2748 by modifying the contents of
the Client-Accept message. 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 Security ClientSI Object..................................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..........................4 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............................5 5.2 PDP Initiated Security Negotiation............................6
6 Connection Closure.............................................6 6 Connection Closure.............................................6
6.1 PEP System Behavior...........................................6 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.....................7
7.1 PDP Identity..................................................8 7.1 PDP Identity..................................................8
7.2 PEP Identity..................................................8 7.2 PEP Identity..................................................9
8 Backward Compatibility.........................................9 8 Backward Compatibility.........................................9
9 IANA Considerations.............................................9 9 IANA Considerations.............................................9
10 Security Considerations........................................9 10 Security Considerations.......................................10
11 References.....................................................9 11 References....................................................10
11.1 Normative References........................................10 11.1 Normative References........................................10
11.2 Informative References......................................10 11.2 Informative References......................................10
12 Author Addresses.............................................10 12 Author Addresses.............................................11
13 IPR Disclosure Acknowledgement...............................10 13 IPR Disclosure Acknowledgement...............................11
14 Disclaimer of Validity.......................................11 14 Disclaimer of Validity.......................................11
15 Copyright Statement..........................................11 15 Copyright Statement..........................................11
16 Disclaimer...................................................11 16 Disclaimer...................................................12
17 Acknowledgements.............................................11 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].
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 confidentiality. This is
some organizations find it necessary to hide some or all of their because some organizations find it necessary to hide some or all of
security policies, e.g., because policy distribution to devices such their security policies, e.g., because policy distribution to
as mobile platforms can cross domain boundaries. devices such as mobile platforms can cross domain boundaries.
TLS [RFC2246] was designed to provide channel-oriented security. TLS TLS [RFC2246] was designed to provide channel-oriented security. TLS
standardizes SSL and may be used with any connection-oriented standardizes SSL and may be used with any connection-oriented
service. TLS provides mechanisms for both one- and two-way service. TLS provides mechanisms for both one- and two-way
authentication, dynamic session keying, and data stream privacy and authentication, dynamic session keying, and data stream privacy and
integrity. integrity.
This document describes how to use COPS over TLS. "COPS over TLS" is This document describes how to use COPS over TLS. "COPS over TLS" is
abbreviated COPS/TLS. abbreviated COPS/TLS.
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 Security ClientSI Object 4.1 The TLS Message Integrity Object (Integrity-TLS)
The Security ClientSI object is used by the PDP and the PEP to start The TLS Integrity object is used by the PDP and the PEP to start the
the TLS negotiation. This object should be included only in the TLS negotiation. This object should be included only in the Client-
Client-Open or Client-Accept messages. It MUST NOT be included in Open or Client-Accept messages. It MUST NOT be included in any other
any other COPS message. COPS message.
0 1 2 3 0 1 2 3
+----------+----------+----------+----------+ +----------+----------+----------+----------+
| Length (Octets) | C-Num=9 | C-Type=2 | | Length (Octets) | C-Num=16 | C-Type=2 |
+----------+----------+----------+----------+ +----------+----------+----------+----------+
| //////// | Flags | | //////// | Flags |
+----------+----------+----------+----------+ +----------+----------+----------+----------+
Note: //// implies the field is reserved, set to 0 and should be Note: //// implies the field is reserved, set to 0 and should be
ignored on receipt. ignored on receipt.
Flags: 16 bits Flags: 16 bits
0x01 = StartTLS 0x01 = StartTLS
This flag indicates that the sender of the message wishes to This flag indicates that the sender of the message
initiate a TLS handshake. wishes to initiate a TLS handshake.
The Client-Type of any message containing this Named ClientSI object The Client-Type of any message containing this object MUST be 0.
MUST be 0. Client-Type 0 is used to negotiate COPS connection level Client-Type 0 is used to negotiate COPS connection level security
security and must only be used during the connection establishment and must only be used during the connection establishment phase.
phase. Please refer to section 4.1 of [RFC2748] for more details. 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 uses the error codes described in section 2.2.8 (Error
(Error Object) of [RFC2748]. Object) of [RFC2748].
Error Code: error-code-TBD-by-IANA = TLS Required Error Code: 13= Unknown COPS Object:
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 will be 16 and the C-Type will be 2. This
demonstrates that the TLS version of the Integrity object not known.
This error code should be used by either PEP or PDP to indicate a This error code should be used by either PEP or PDP to indicate a
security-related connection closure. 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 should send the
following error code:
Error Code: 15= Authentication Required
Where the Sub-code (octet 2) contains the C-Num=16 value for the
Integrity Object and (octet 3) will specify the PDP
required/preferred Integrity object C-Type. If the server does not
support any form of COPS-Security, it will 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 either by the PDP or the PEP. Security negotiation may be initiated either by the PDP or the PEP.
The PEP can initiate a negotiation via a Client-Open message, while The PEP can initiate a negotiation via a Client-Open message, while
a PDP can initiate a negotiation via a Client-Accept message. a PDP can initiate a negotiation via a Client-Accept 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 PEP Initiated Security Negotiation 5.1 PEP Initiated Security Negotiation
A PEP MAY initiate security negotiation with a PDP using the Client- A PEP MAY initiate a TLS security negotiation with a PDP using the
Open message. The Client-Open message MUST have a Client-Type of 0 Client-Open message. To do this, the Client-Open message MUST have a
and MUST include the Security ClientSI object. Client-Type of 0 and MUST include the Integrity-TLS object.
Upon receiving the Client-Open message, the PDP SHOULD respond with Upon receiving the Client-Open message, the PDP SHOULD respond with
a Client-Accept message containing the Security ClientSI object. a Client-Accept message containing the Integrity-TLS object.
Note that in order to carry the Security ClientSI object, the Note that in order to carry the Integrity-TLS object, the contents
contents of the Client-Accept message defined in section 3.7 of of the Client-Accept message defined in section 3.7 of [RFC2748]
[RFC2748] need to change to the following: need not change, other than the C-Type of the integrity object
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>]
[<ClientSI>] [<Integrity (C-Num=16, C-Type=2)>]
[<Integrity>]
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, Security) C: Client-Open (Client-Type = 0, Integrity-TLS)
S: Client-Accept (Client-Type = 0, Security) S: Client-Accept (Client-Type = 0, Integrity-TLS)
<TLS handshake> <TLS handshake>
C/S: <...further messages...> C/S: <...further messages...>
Instead of sending a Client-Accept message, the PDP may choose to In case the PDP does not wish to open a secure connection with the
close the connection if it does not wish to open a secure connection PEP, it MUST reply with a Client-Close message and close the
with the PEP. It MUST include the error code error-code-TBD-by-IANA connection. The Client-Close message MUST include the error code
in the ensuing Client-Close message. 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 expecting the Security ClientSI object in a Client-Accept A PEP requiring the Integrity-TLS object in a Client-Accept message
message MUST close the connection if the ClientSI object is missing. MUST close the connection if the Integrity-TLS object is missing. It
It MUST include the error code error-code-TBD-by-IANA in the ensuing MUST include the error code 15= Authentication required, with the
Client-Close message. 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, in the ensuing Client-Close message.
5.2 PDP Initiated Security Negotiation 5.2 PDP Initiated Security Negotiation
The PEP initially opens a TCP connection with the PDP on the The PEP initially opens a TCP connection with the PDP on the
standard COPS port and sends a Client-Open message. This Client-Open standard COPS port and sends a Client-Open message. This Client-Open
message MUST have a Client-Type of 0. message MUST have a Client-Type of 0.
The PDP SHOULD then reply with a Client-Accept message. In order to 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 signal the PEP to start the TLS handshake, the PDP MUST include the
Security ClientSI object in the Client-Accept message. Integrity-TLS object in the Client-Accept message.
Upon receiving the Client-Accept message with the Security ClientSI Upon receiving the Client-Accept message with the Integrity-TLS
object, the PEP SHOULD initiate the TLS handshake. If for any reason object, the PEP SHOULD initiate the TLS handshake. If for any reason
the PEP cannot initiate the handshake, it MUST close the connection. the PEP cannot initiate the handshake, it MUST close the connection.
The message exchange is as follows: The message exchange is as follows:
C: Client-Open (Client-Type = 0) C: Client-Open (Client-Type = 0)
S: Client-Accept (Client-Type = 0, Security) S: Client-Accept (Client-Type = 0, Integrity-TLS)
<TLS handshake> <TLS handshake>
C/S: <...further messages...> C/S: <...further messages...>
Before completion of the TLS handshake, the PEP MUST NOT send any After receiving the Client-Accept, the PEP MUST NOT send any
messages other than Client-Close and Keep-Alive. Upon receiving any messages until the TLS handshake is complete. Upon receiving any
other message, a PDP expecting a TLS negotiation MUST issue a message from the PEP before the TLS handshake starts, the PDP MUST
Client-Close message with an error code of error-code-TBD-by-IANA. issue a Client-Close message with an error code 15= Authentication
Required.
A PDP wishing to negotiate security with a PEP having a non-secure A PDP wishing to negotiate security with a PEP having an existing
connection MUST send a Client-Close with the error code error-code- non-secure connection MUST send a Client-Close with the error code
TBD-by-IANA and wait for the PEP to reconnect. Upon receiving the 15= Authentication required, with the Sub-code (octet 2) containing
Client-Open message, it SHOULD use the Client-Accept message to the required Integrity object's C-Num=16 and (octet 3) containing
initiate security negotiation. the required Integrity object's C-Type=2 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
is known as an "incomplete close". TLS allows implementations to is known as an "incomplete close". TLS allows implementations to
reuse the session in this case, but COPS/TLS makes no use of this reuse the session in this case, but COPS/TLS makes no use of this
capability. capability.
skipping to change at page 8, line 26 skipping to change at page 8, line 52
7.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 trust
certificates of authorized Certificate Authorities that issue PDP anchor for each authorized Certification Authority (CA) that issues
certificates. Also, the PEPs MUST support a mechanism to securely PDP certificates. Also, the PEPs MUST support a mechanism to
acquire an access control list or filter identifying the CA's set of securely acquire an access control list or filter identifying the
authorized PDPs. set of authorized PDPs associated with each CA.
PEP deployments that participate in multiple domains, such as those PEP deployments that participate in multiple domains, such as those
on mobile platforms, MAY use different CAs and access control lists on mobile platforms, MAY use different CAs and access control 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
skipping to change at page 9, line 4 skipping to change at page 9, line 30
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.
7.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 the subjects
the sense of [RFC3280]. In this case, COPS over TLS uses two-way of end entity certificates [RFC3280]. In this case, COPS over TLS
authentication, and the PDP MUST perform the same identity checks uses two-way authentication, and the PDP MUST perform the same
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 signing certificates MUST have a mechanism to securely acquire the trust anchor for each
of the Certificate Authorities issuing certificates to any of the authorized Certification Authority (CA) that issues certificates to
PEPs they support. 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 Security ClientSI 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 IANA shall add the following Error-Code to the cops-parameters
registry located at http://www.iana.org/assignments/cops-parameters.
Error-Code: error-code-TBD-by-IANA
Description: TLS Required
For the Named ClientSI object for Client-Type 0, the IANA shall add
the following Flags value: the following Flags value:
0x01 = StartTLS 0x01 = StartTLS
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.
A man-in-the-middle attack can be launched by deleting the Security A man-in-the-middle attack can be launched by deleting the
ClientSI object from the Client-Open or Client-Accept messages. To Integrity-TLS object or altering the Client-Open or Client-Accept
prevent this, the PEP and PDP MUST use the Integrity object as messages. If security is required, the PEP and PDP bootstrap policy
defined in [RFC2748]. must specify this, and PEP and PDP implementations should reject
Client-Open or Client-Accept messages that fail to include an
Integrity-TLS object.
11 References 11 References
11.1 Normative References 11.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.
skipping to change at page 10, line 39 skipping to change at page 11, line 9
[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.
[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
Jesse R. Walker Amol Kulkarni
Intel Corporation Intel Corporation
2111 N.E. 25th Avenue 2111 N.E. 25th Avenue
Hillsboro, OR 97214 Hillsboro, OR 97214
USA USA
jesse[dot]walker[at]intel[dot]com amol[dot]kulkarni[at]intel[dot]com
Amol Kulkarni Jesse R. Walker
Intel Corporation Intel Corporation
JF3-206
2111 N.E. 25th Avenue 2111 N.E. 25th Avenue
Hillsboro, OR 97214 Hillsboro, OR 97214
USA USA
amol[dot]kulkarni[at]intel[dot]com jesse[dot]walker[at]intel[dot]com
13 IPR Disclosure Acknowledgement 13 IPR Disclosure Acknowledgement
By submitting this Internet-Draft, we certify that any applicable By submitting this Internet-Draft, we certify that any applicable
patent or other IPR claims of which we are aware have been patent or other IPR claims of which we are aware have been
disclosed, and any of which we become aware will be disclosed, in disclosed, and any of which we become aware will be disclosed, in
accordance with RFC 3668. accordance with RFC 3668.
14 Disclaimer of Validity 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 Rights or other rights that might be claimed Intellectual Property Rights or other rights that might be claimed
to pertain to the implementation or use of the technology described to pertain to the implementation or use of the technology described
 End of changes. 

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