draft-ietf-rserpool-threats-03.txt   draft-ietf-rserpool-threats-04.txt 
Internet Engineering Task Force Maureen Stillman(editor) Internet Engineering Task Force Maureen Stillman(editor)
INTERNET DRAFT Ram Gopal INTERNET DRAFT Ram Gopal
Senthil Sengodan Senthil Sengodan
Nokia Nokia
Erik Guttman Erik Guttman
Sun Microsystems Sun Microsystems
Matt Holdrege Matt Holdrege
Strix Systems Strix Systems
08 July 2004 04 January 2005
expires January 8, 2005 expires July 4, 2005
Threats Introduced by Rserpool and Requirements for Security Threats Introduced by Rserpool and Requirements for Security
in response to Threats in response to Threats
<draft-ietf-rserpool-threats-03.txt> <draft-ietf-rserpool-threats-04.txt>
Status of This Memo Status of This Memo
By submitting this Internet-Draft, I certify that any applicable By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed, patent or other IPR claims of which I am aware have been disclosed,
and any of which I become aware will be disclosed, in accordance with and any of which I become aware will be disclosed, in accordance with
RFC 3668. RFC 3668.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 41 skipping to change at page 1, line 41
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
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.
This Internet-Draft will expire on January 8, 2004. This Internet-Draft will expire on July 4, 2005.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved. Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract Abstract
Rserpool is an architecture and set of protocols for the management Rserpool is an architecture and set of protocols for the management
and access to server pools supporting highly reliable applications and access to server pools supporting highly reliable applications
and for client access mechanisms to a server pool. This Internet and for client access mechanisms to a server pool. This Internet
skipping to change at page 2, line 19 skipping to change at page 2, line 19
1. Introduction 3 1. Introduction 3
1.1 Definitions . . . . . . . . . . . . . . . . . . . . . . . 3 1.1 Definitions . . . . . . . . . . . . . . . . . . . . . . . 3
2. Threats 4 2. Threats 4
2.1 PE Registration/Deregistration flooding . . . . . . . . . 4 2.1 PE Registration/Deregistration flooding . . . . . . . . . 4
2.2 PE Registration/Deregistration flooding . . . . . . . . . 4 2.2 PE Registration/Deregistration flooding . . . . . . . . . 4
2.3 PE Registration/Deregistration spoofing . . . . . . . . . 4 2.3 PE Registration/Deregistration spoofing . . . . . . . . . 4
2.4 PE Registration/Deregistration unauthorized . . . . . . . 5 2.4 PE Registration/Deregistration unauthorized . . . . . . . 5
2.5 Malicious ENRP server joins the group of legitimate ENRP 2.5 Malicious ENRP server joins the group of legitimate ENRP
servers . . . . . . . . . . . . . . . . . 5 servers . . . . . . . . . . . . . . . . . 5
2.6 Registration/deregistration with malicious ENRP servers . 5 2.6 Registration/deregistration with malicious ENRP servers . 5
2.7 Malicious ENRP Name Resolution .. . . . . . . . . . . . . 5 2.7 Malicious ENRP Handlespace Resolution . . . . . . . . . . 5
2.8 Malicious node performs a replay attack.. . . . . . . . . 6 2.8 Malicious node performs a replay attack.. . . . . . . . . 6
2.9 Re-establishing PU-PE security during failover. . . . . . 6 2.9 Re-establishing PU-PE security during failover. . . . . . 6
2.10 Integrity . . . . . . . . . . . . . . . . . . . . . . . . 6 2.10 Integrity . . . . . . . . . . . . . . . . . . . . . . . . 6
2.11 Data Confidentiality . . . . . . . . . . . . . . . . . . 6 2.11 Data Confidentiality . . . . . . . . . . . . . . . . . . 6
2.12 ENRP Server Discovery . . . . . . . . . . . . . . . . . . 7 2.12 ENRP Server Discovery . . . . . . . . . . . . . . . . . . 7
2.13 Flood of endpoint unreachable messages . . . . . . . . . 7 2.13 Flood of endpoint unreachable messages . . . . . . . . . 7
2.14 Flood of endpoint keep alive messages . . . . . . . . . . 7 2.14 Flood of endpoint keep alive messages . . . . . . . . . . 7
3. Security Considerations . . . . . . . . . . . . . . . . . . . . 8 3. Security Considerations . . . . . . . . . . . . . . . . . . . . 8
3.1 Database security . . . . . . . . . . . . . . . . . . . . 10 3.1 Database security . . . . . . . . . . . . . . . . . . . . 10
3.2 Cookie security . . . . . . . . . . . . . . . . . . . . . 10 3.2 Cookie security . . . . . . . . . . . . . . . . . . . . . 10
skipping to change at page 3, line 10 skipping to change at page 3, line 10
5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 11 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 11
7. Intellectual Property Statement . . . . . . . . . . . . . . . . 12 7. Intellectual Property Statement . . . . . . . . . . . . . . . . 12
8. Author's addresses . . . . . . . . . . . . . . . . . . . . . . . 13 8. Author's addresses . . . . . . . . . . . . . . . . . . . . . . . 13
1. Introduction 1. Introduction
RSERPOOL provides a session layer for robustness. The session layer RSERPOOL provides a session layer for robustness. The session layer
function may redirect communication transparently to upper layers. This function may redirect communication transparently to upper layers. This
alters the direct one-to-one association between communicating endpoints alters the direct one-to-one association between communicating endpoints
which typically exists between clients and services. In particular, which typically exists between clients and servers. In particular,
secure operation of protocols often relies on assumptions at different secure operation of protocols often relies on assumptions at different
layers regarding the identity of the communicating party and the layers regarding the identity of the communicating party and the
continuity of the communication between endpoints. Further, the continuity of the communication between endpoints. Further, the
operation of RSERPOOL itself has security implications and risks. The operation of RSERPOOL itself has security implications and risks. The
session layer operates dynamically which imposes additional concerns for session layer operates dynamically which imposes additional concerns for
the overall security of the end-to-end application. This document the overall security of the end-to-end application. This document
explores the security implications of RSERPOOL, both due to its own explores the security implications of RSERPOOL, both due to its own
functions and due to its being interposed between applications and functions and due to its being interposed between applications and
transport interfaces. transport interfaces.
1.1 Definitions 1.1 Definitions
This document uses the following terms: This document uses the following terms:
ENRP Endpoint Name Resolution Protocol: ENRP Endpoint haNdlespace Redundancy Protocol:
Within the operational scope of Rserpool, ENRP defines the Within the operational scope of Rserpool, ENRP defines the
procedures and message formats of a distributed fault-tolerant procedures and message formats of a distributed fault-tolerant
registry service for storing, bookkeeping, retrieving, and registry service for storing, bookkeeping, retrieving, and
distributing pool operation and membership information. distributing pool operation and membership information.
ASAP Aggregate Server Access Protocol: ASAP Aggregate Server Access Protocol:
A session layer protocol which uses the Endpoint Name A session layer protocol which uses the Endpoint haNdlespace
Resolution Protocol (ENRP) to provide a high Reduncancy Protocol to provide a high availability
availability name space. ASAP is responsible for the handlespace. ASAP is responsible for the abstraction of the
abstraction of the underlying transport technologies, load underlying transport technologies, load distribution
distribution management,fault management, as well as the management,fault management, as well as the presentation to
presentation to the upper layer (i.e., the ASAP user) a the upper layer (i.e., the ASAP user) a unified primitive
unified primitive interface. interface.
Operation scope: Operational scope:
The part of the network visible to pool users by a specific The part of the network visible to pool users by a specific
instance of the reliable server pooling protocols. instance of the reliable server pooling protocols.
Pool (or server pool): Pool (or server pool):
A collection of servers providing the same application A collection of servers providing the same application
functionality. functionality.
Pool handle (or pool name): Pool handle:
A logical pointer to a pool. Each server pool will be A logical pointer to a pool. Each server pool will be
identifiable in the operation scope of the system by a unique identifiable in the operational scope of the system by a
pool handle or "name". unique pool handle.
ENRP namespace (or namespace): ENRP handlespace (or handlespace):
A cohesive structure of pool names and relations that may be A cohesive structure of pool names and relations that may be
queried by an internal or external agent. queried by an internal or external agent.
Pool element (PE): Pool element (PE):
A server entity that runs ASAP and has registered to a pool. A server entity that runs ASAP and has registered to a pool.
Pool user (PU): Pool user (PU):
A server pool user that runs ASAP. Note, a PU can also be a A server pool user that runs ASAP. Note, a PU can also be a
PE if it has registered itself to a pool. PE if it has registered itself to a pool.
ENRP namespace server (or ENRP server): ENRP handlepace server (or ENRP server):
Entity which runs ENRP and is responsible for managing and Entity which runs ENRP and is responsible for managing and
maintaining the namespace within the operation scope. maintaining the handlespace within the operational scope.
2. Threats 2. Threats
2.1 PE Registration/Deregistration flooding -- non-existent PE 2.1 PE Registration/Deregistration flooding -- non-existent PE
Threat: A malicious node could send a stream of false Threat: A malicious node could send a stream of false
registrations/deregistrations on behalf of non-existent PEs to ENRP registrations/deregistrations on behalf of non-existent PEs to ENRP
servers at a very rapid rate and thereby create unnecessary state in an servers at a very rapid rate and thereby create unnecessary state in an
ENRP server. ENRP server.
Effect: Corrupting the name server database and/or disabling the Effect: Corrupting the pool registrar database and/or disabling the
Rserpool discovery and naming function. Rserpool discovery and database function.
Requirement: An ENRP server that receives a registration/deregistration Requirement: An ENRP server that receives a registration/deregistration
should not create or update state information until it has authenticated should not create or update state information until it has authenticated
the PE. the PE.
2.2 PE Registration/Deregistration flooding -- unauthorized PE 2.2 PE Registration/Deregistration flooding -- unauthorized PE
Threat: A malicious node or PE could send a stream of Threat: A malicious node or PE could send a stream of
registrations/deregistrations that are unauthorized to registrations/deregistrations that are unauthorized to
register/deregister - to ENRP servers at a very rapid rate and thereby register/deregister - to ENRP servers at a very rapid rate and thereby
create unnecessary state in an ENRP server. create unnecessary state in an ENRP server.
Effect: Corrupting the name server database and/or disabling the Effect: Corrupting the pool registrar database and/or disabling the
Rserpool discovery and naming function. Rserpool discovery and database function.
Requirement: An ENRP server that receives a registration/deregistration Requirement: An ENRP server that receives a registration/deregistration
should not create or update state information until the authorization of should not create or update state information until the authorization of
the registering/de-registering entity is verified. the registering/de-registering entity is verified.
2.3 PE Registration/Deregistration spoofing 2.3 PE Registration/Deregistration spoofing
Threat: A malicious node could send false registrations/deregistrations Threat: A malicious node could send false registrations/deregistrations
to ENRP servers concerning a legitimate PE thereby creating false state to ENRP servers concerning a legitimate PE thereby creating false state
information in the ENRP servers. information in the ENRP servers.
skipping to change at page 5, line 37 skipping to change at page 5, line 37
2.6 Registration/deregistration with malicious ENRP server 2.6 Registration/deregistration with malicious ENRP server
Threat: A PE unknowingly registers/deregisters with malicious ENRP Threat: A PE unknowingly registers/deregisters with malicious ENRP
server. server.
Effect: Registration might not be properly processed or ignored. Effect: Registration might not be properly processed or ignored.
Requirement: PE needs to authenticate the ENRP server. Requirement: PE needs to authenticate the ENRP server.
2.7 Malicious ENRP Name Resolution 2.7 Malicious ENRP Handlespace Resolution
Threat: The ASAP protocol receives a name resolution response from an Threat: The ASAP protocol receives a handlespace resolution response
ENRP server, but the ENRP server is malicious and returns random IP from an ENRP server, but the ENRP server is malicious and returns random
addresses or an inaccurate list in response to the pool handle. IP addresses or an inaccurate list in response to the pool handle.
Effect: PU application communicates with the wrong PE or is unable to Effect: PU application communicates with the wrong PE or is unable to
locate the PE since the response is incorrect in saying that a PE with locate the PE since the response is incorrect in saying that a PE with
that name did not exist. that handle did not exist.
Requirement: ASAP needs to authenticate the ENRP server. Requirement: ASAP needs to authenticate the ENRP server.
2.8 Malicious node performs a replay attack 2.8 Malicious node performs a replay attack
Threat: A malicious node could replay the entire message previously sent Threat: A malicious node could replay the entire message previously sent
by a legitimate entity. This could create false/unnecessary state in the by a legitimate entity. This could create false/unnecessary state in the
ENRP servers when the replay is for registration/de-registration or ENRP servers when the replay is for registration/de-registration or
update. update.
skipping to change at page 6, line 34 skipping to change at page 6, line 34
between PU and PE B. This will violate security policy. between PU and PE B. This will violate security policy.
Requirement: Either notify the application when fail over occurs so the Requirement: Either notify the application when fail over occurs so the
application can take appropriate action to establish a trusted application can take appropriate action to establish a trusted
relationship with PE B OR reestablish the security context relationship with PE B OR reestablish the security context
transparently. transparently.
2.10 Integrity 2.10 Integrity
Threats: Threats:
a) ENRP response to name resolution is corrupted during transmission a) ENRP response to pool handle resolution is corrupted during
transmission
b) ENRP peer messages are corrupted during transmission b) ENRP peer messages are corrupted during transmission
c) PE sends update for values and that information is corrupted during c) PE sends update for values and that information is corrupted during
transmission transmission
Effect: ASAP receives corrupt information for pool handle resolution Effect: ASAP receives corrupt information for pool handle resolution
which the PU believes to be accurate. which the PU believes to be accurate.
Requirement: Integrity mechanism needed. Requirement: Integrity mechanism needed.
2.11 Data Confidentiality 2.11 Data Confidentiality
Threat: An eavesdropper capable of snooping on fields within messages in Threat: An eavesdropper capable of snooping on fields within messages in
transit, may be able to garner information such as topology/location/IP transit, may be able to garner information such as topology/location/IP
addresses etc. that may not be desirable to divulge. addresses etc. that may not be desirable to divulge.
Effect: Information that an administrator does not wish to divulge are Effect: Information that an administrator does not wish to divulge are
divulged. divulged.
Requirement: Provision for Data confidentiality service. Requirement: Provision for data confidentiality service.
2.12 ENRP Server Discovery 2.12 ENRP Server Discovery
Threat A: Thwarting successful discovery: When a PE wishes to register Threat A: Thwarting successful discovery: When a PE wishes to register
with an ENRP server, it needs to discover an ENRP server. An attacker with an ENRP server, it needs to discover an ENRP server. An attacker
could thwart the successful discovery of ENRP server(s) thereby inducing could thwart the successful discovery of ENRP server(s) thereby inducing
the PE to believe that no ENRP server is available. For instance, the the PE to believe that no ENRP server is available. For instance, the
attacker could reduce the returned set of ENRP servers to null or a attacker could reduce the returned set of ENRP servers to null or a
small set of inactive ENRP servers. small set of inactive ENRP servers.
skipping to change at page 8, line 14 skipping to change at page 8, line 14
3. Security Considerations for Rserpool 3. Security Considerations for Rserpool
This informational document characterizes potential security threats This informational document characterizes potential security threats
targeting the Rserpool architecture. The security mechanisms required targeting the Rserpool architecture. The security mechanisms required
to mitigate these threats are summarized for each architectural to mitigate these threats are summarized for each architectural
component. It will be noted which mechanisms are required and which are component. It will be noted which mechanisms are required and which are
optional. optional.
From the threats described in this document, the security services From the threats described in this document, the security services
required required for the Rserpool protocol are enumerated below.
for the Rserpool protocol are enumerated below.
Threat 2.1, 2.2, 2.3, 2.4) PE registration/deregistration flooding Threat 2.1, 2.2, 2.3, 2.4) PE registration/deregistration flooding
and/or spoofing. and/or spoofing.
Security mechanism in response: ENRP server authenticates the PE Security mechanism in response: ENRP server authenticates the PE
Threat 2.6) PE registers with a malicious ENRP server Threat 2.6) PE registers with a malicious ENRP server
Security mechanism in response: PE authenticates the ENRP server Security mechanism in response: PE authenticates the ENRP server
These combined threats result in a requirement for mutual authentication These combined threats result in a requirement for mutual authentication
of the ENRP server and the PE. of the ENRP server and the PE.
Threat 2.5) Malicious ENRP server joins the ENRP server pool Threat 2.5) Malicious ENRP server joins the ENRP server pool
Security mechanism in response: ENRP servers mutually authenticate Security mechanism in response: ENRP servers mutually authenticate
Threat 2.7, 2.12) A PU communicates with a malicious ENRP server for Threat 2.7, 2.12) A PU communicates with a malicious ENRP server for
name resolution handlespace resolution
Security mechanism in response: The PU authenticates the ENRP server. Security mechanism in response: The PU authenticates the ENRP server.
If the authentication fails, it looks for another ENRP server. If the authentication fails, it looks for another ENRP server.
Threat 2.8) Replay attack Threat 2.8) Replay attack
Security mechanism in response: Security protocol which has protection Security mechanism in response: Security protocol which has protection
from replay attacks from replay attacks
Threat 2.9) Re-establishing PU-PE security during failover Threat 2.9) Re-establishing PU-PE security during failover
Requirement: Either notify the application when fail over occurs so the Requirement: Either notify the application when fail over occurs so the
application can take appropriate action to establish a trusted application can take appropriate action to establish a trusted
relationship with PE B OR reestablish the security context relationship with PE B OR reestablish the security context
transparently. transparently.
Threat 2.10) Corrupted data which causes a PU to have misinformation Threat 2.10) Corrupted data which causes a PU to have misinformation
concerning a name resolution concerning a pool handle resolution
Security mechanism in response: Security protocol which supports Security mechanism in response: Security protocol which supports
integrity protection integrity protection
Threat 2.11) Eavesdropper snooping on namespace information Threat 2.11) Eavesdropper snooping on handlespace information
Security mechanism in response: Security protocol which supports data Security mechanism in response: Security protocol which supports data
confidentiality confidentiality
To summarize the threats 2.1-2.12 require security mechanisms which To summarize the threats 2.1-2.12 require security mechanisms which
support authentication, integrity, data confidentiality and protection support authentication, integrity, data confidentiality and protection
from replay attacks. from replay attacks.
For Rserpool we need to authenticate the following: For Rserpool we need to authenticate the following:
PU -----> ENRP Server (PU authenticates the ENRP server) PU -----> ENRP Server (PU authenticates the ENRP server)
PE <----> ENRP Server (mutual authentication) PE <----> ENRP Server (mutual authentication)
ENRP server <-----> ENRP Server (mutual authentication) ENRP server <-----> ENRP Server (mutual authentication)
Summary by component: Summary by component:
Rserpool client -- mandatory to implement authentication of the ENRP Rserpool client -- mandatory to implement authentication of the ENRP
server is required for accurate name resolution. This is to protect server is required for accurate pool handle resolution. This is to
against threats from rogue ENRP servers. In addition, confidentiality, protect against threats from rogue ENRP servers. In addition,
integrity and preventing replay attack are also mandatory to implement confidentiality, integrity and preventing replay attack are also
to protect from eavesdropping and data corruption or false data mandatory to implement to protect from eavesdropping and data corruption
transmission. Confidentiality is mandatory to implement and is used or false data transmission. Confidentiality is mandatory to implement
when and is used when privacy is required.
privacy is required.
PE to ENRP communications -- mandatory to implement mutual PE to ENRP communications -- mandatory to implement mutual
authentication, integrity and protection from replay attack is required authentication, integrity and protection from replay attack is required
for PE to ENRP communications. This is to protect the integrity of the for PE to ENRP communications. This is to protect the integrity of the
ENRP name space database. Confidentiality is mandatory to implement and ENRP handle space database. Confidentiality is mandatory to implement
is used when privacy is required. and is used when privacy is required.
ENRP to ENRP communications -- mandatory to implement mutual ENRP to ENRP communications -- mandatory to implement mutual
authentication, integrity and protection from replay attack is required authentication, integrity and protection from replay attack is required
for ENRP to ENRP communications. This is to protect the integrity of for ENRP to ENRP communications. This is to protect the integrity of
the ENRP name space database. Confidentiality is mandatory to implement the ENRP handle space database. Confidentiality is mandatory to
and is used when privacy is required. implement and is used when privacy is required.
Threat 2.13) Flood of Endpoint_Unreachable messages from the PU to ENRP Threat 2.13) Flood of Endpoint_Unreachable messages from the PU to ENRP
server server
Security mechanism in response: ASAP must control the number of endpoint Security mechanism in response: ASAP must control the number of endpoint
unreachable messages transmitted from the PU to the ENRP server. unreachable messages transmitted from the PU to the ENRP server.
Threat 2.14) Flood of Endpoint_KeepAlive messages to the PE from the Threat 2.14) Flood of Endpoint_KeepAlive messages to the PE from the
ENRP server ENRP server
Security mechanism in response: ENRP server must control the number of Security mechanism in response: ENRP server must control the number of
Endpoint_KeepAlive messages to the PE Endpoint_KeepAlive messages to the PE
3.1 Security of the ENRP Database 3.1 Security of the ENRP Database
Another consideration involves the security characteristics of the Another consideration involves the security characteristics of the
ENRP database. Suppose that some of the PEs register with an ENRP ENRP database. Suppose that some of the PEs register with an ENRP
server using security and some do not. In this case, when a client server using security and some do not. In this case, when a client
requests name resolution information from ENRP, it would have to be requests handle space resolution information from ENRP, it would have to
informed which entries are "secure" and which are not. This would not be informed which entries are "secure" and which are not. This would
only complicate the protocol, but actually bring into question the not only complicate the protocol, but actually bring into question the
security and integrity of such a database. What can be asserted about security and integrity of such a database. What can be asserted about
the security of such a database is a very thorny question. Due to these the security of such a database is a very thorny question. Due to these
two facts it was decided that either the entire ENRP server database is two facts it was decided that either the entire ENRP server database is
secure, that is, it has registrations exclusively from PEs secure, that is, it has registrations exclusively from PEs
that have used security mechanisms or the entire database is insecure, that have used security mechanisms or the entire database is insecure,
that is, registrations are from PEs that have used no security that is, registrations are from PEs that have used no security
mechanisms. ENRP servers that support security are required to reject mechanisms. ENRP servers that support security are required to reject
any PE server registration that does not use the security mechanisms. any PE server registration that does not use the security mechanisms.
Likewise, ENRP servers that support security should not accept updates Likewise, ENRP servers that support security should not accept updates
from other ENRP servers that do not use security mechanisms. from other ENRP servers that do not use security mechanisms.
skipping to change at page 11, line 14 skipping to change at page 11, line 14
4. IANA Considerations 4. IANA Considerations
This document introduces no additional considerations for IANA. This document introduces no additional considerations for IANA.
5. References 5. References
Normative References: Normative References:
[Rserarch] M. Tuexen, et. al., "Architecture for Reliable Server [Rserarch] M. Tuexen, et. al., "Architecture for Reliable Server
Pooling", draft-ietf-reserpool-arch-06.txt, June, 2003, work in Pooling", draft-ietf-reserpool-arch-08.txt, October, 2004, work in
progress. progress.
Informative References: Informative References:
[RFC2026] S. Bradner, "The Internet Standards Process -- Revision 3", [RFC2026] S. Bradner, "The Internet Standards Process -- Revision 3",
RFC 2026, October 1996. RFC 2026, October 1996.
[RFC3365] RFC 3365, Strong Security Requirements for IETF Standard [RFC3365] RFC 3365, Strong Security Requirements for IETF Standard
Protocols, August, 2002. Protocols, August, 2002.
skipping to change at page 13, line 5 skipping to change at page 13, line 5
of such proprietary rights by implementers or users of this of such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository specification can be obtained from the IETF on-line IPR repository
at http://www.ietf.org/ipr. at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention The IETF invites any interested party to bring to its attention
any copyrights, patents or patent applications, or other any copyrights, patents or patent applications, or other
proprietary rights that may cover technology that may be required proprietary rights that may cover technology that may be required
to implement this standard. Please address the information to the to implement this standard. Please address the information to the
IETF at ietf-ipr@ietf.org. IETF at ietf-ipr@ietf.org.
expires 08 January 2005 expires 04 July 2005
8. Author's Addresses 8. Author's Addresses
Ram Gopal Ram Gopal
Nokia Research Center Nokia Research Center
5 Wayside Road 5 Wayside Road
Burlington, MA 01803 Burlington, MA 01803
USA USA
email: ram.gopal@nokia.com email: ram.gopal@nokia.com
 End of changes. 

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