draft-ietf-nfsv4-secinfo-00.txt   draft-ietf-nfsv4-secinfo-01.txt 
Network Working Group M. Eisler Network Working Group M. Eisler
Internet-Draft Editor Internet-Draft Editor
Document: draft-ietf-nfsv4-secinfo-00.txt Network Appliance, Inc. Document: draft-ietf-nfsv4-secinfo-01.txt Network Appliance, Inc.
May 2003 June 2004
NFSv4.1: SECINFO Changes NFSv4.1: SECINFO Changes
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance By submitting this Internet-Draft, I certify that any applicable
with all provisions of Section 10 of RFC2026. patent or other IPR claims of which I am aware have been disclosed,
or will be disclosed, and any of which I become aware will be
disclosed, in accordance with RFC 3668.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as other groups may also distribute working documents as
Internet-Drafts. Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six Internet-Drafts are draft documents valid for a maximum of six months
months and may be updated, replaced, or obsoleted by other and may be updated, replaced, or obsoleted by other documents at any
documents at any time. It is inappropriate to use Internet- time. It is inappropriate to use Internet-Drafts as reference
Drafts as reference material or to cite them other than as material or to cite them other than a "work in progress."
"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/1id-abstracts.html http://www.ietf.org/1id-abstracts.html
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"
ABSTRACT ABSTRACT
This document proposes some changes to security negotiation in NFS This document proposes some changes to security negotiation in NFS
version 4 [RFC3530]. It is hoped that these changes will be part of a version 4 [RFC3530]. It is hoped, but not promised, that these
new minor version of NFS: NFSv4.1. changes will be part of a new minor version of NFS: NFSv4.1.
TABLE OF CONTENTS TABLE OF CONTENTS
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Modified Operation 33: SECINFO - Obtain Available Security . . 2 2. Modified Operation 16: LOOKUPP - Lookup Parent Directory . . . 2
3. New Operation 40: SECINFO_NO_NAME - Get Security on Unnamed 3. Modified Operation 33: SECINFO - Obtain Available Security . . 4
Object . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 4. New Operation 40: SECINFO_NO_NAME - Get Security on Unnamed
4. Clarification of Security Negotiation in NFSv4.1 . . . . . . . 7 Object . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.1. PUTFH + LOOKUP . . . . . . . . . . . . . . . . . . . . . . . 7 5. Clarification of Security Negotiation in NFSv4.1 . . . . . . . 8
4.2. PUTFH + LOOKUPP . . . . . . . . . . . . . . . . . . . . . . 8 5.1. PUTFH + LOOKUP . . . . . . . . . . . . . . . . . . . . . . . 9
4.3. PUTFH + SECINFO . . . . . . . . . . . . . . . . . . . . . . 8 5.2. PUTFH + LOOKUPP . . . . . . . . . . . . . . . . . . . . . . 9
4.4. PUTFH + Anything Else . . . . . . . . . . . . . . . . . . . 8 5.3. PUTFH + SECINFO . . . . . . . . . . . . . . . . . . . . . . 9
5. RPC Definition File Changes . . . . . . . . . . . . . . . . . 9 5.4. PUTFH + Anything Else . . . . . . . . . . . . . . . . . . 10
6. Security Considerations . . . . . . . . . . . . . . . . . . 12 6. RPC Definition File Changes . . . . . . . . . . . . . . . . 10
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . 12 7. Security Considerations . . . . . . . . . . . . . . . . . . 13
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . 13
9. Normative References . . . . . . . . . . . . . . . . . . . . 12 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13
10. Informative References . . . . . . . . . . . . . . . . . . 13 10. Normative References . . . . . . . . . . . . . . . . . . . 14
11. Editor's Address . . . . . . . . . . . . . . . . . . . . . 13 11. Informative References . . . . . . . . . . . . . . . . . . 14
12. IPR Notices . . . . . . . . . . . . . . . . . . . . . . . . 13 12. Editor's Address . . . . . . . . . . . . . . . . . . . . . 14
13. Copyright Notice . . . . . . . . . . . . . . . . . . . . . 14 13. IPR Notices . . . . . . . . . . . . . . . . . . . . . . . . 15
14. Copyright Notice . . . . . . . . . . . . . . . . . . . . . 15
1. Introduction 1. Introduction
This document assumes understanding of the NFSv4.0 specification. This document assumes understanding of the NFSv4.0 specification.
The NFSv4.0 specification contains three oversights and ambiguities The NFSv4.0 specification contains three oversights and ambiguities
with respect to the SECINFO operation. with respect to the SECINFO operation.
First, it is impossible for the client to use the SECINFO operation First, it is impossible for the client to use the SECINFO operation
to determine the correct security triple for accessing a parent to determine the correct security triple for accessing a parent
skipping to change at page 2, line 47 skipping to change at page 2, line 49
Third, there is a problem as to what the client must do (or can do), Third, there is a problem as to what the client must do (or can do),
whenever the server returns NFS4ERR_WRONGSEC in response to a PUTFH whenever the server returns NFS4ERR_WRONGSEC in response to a PUTFH
operation. The NFSv4.0 specification says that client should issue a operation. The NFSv4.0 specification says that client should issue a
SECINFO using the parent filehandle and the component name of the SECINFO using the parent filehandle and the component name of the
filehandle that PUTFH was issued with. This may not be convenient for filehandle that PUTFH was issued with. This may not be convenient for
the client. the client.
This document resolves the above three issues in the context of This document resolves the above three issues in the context of
NFSv4.1. NFSv4.1.
2. Modified Operation 33: SECINFO - Obtain Available Security 2. Modified Operation 16: LOOKUPP - Lookup Parent Directory
If the NFSv4 minor version is 1, then following replaces section
14.2.14 of the NFSv4.0 specification. The LOOKUPP operation's "over
the wire" format is not altered, but the semantics are slightly
modified to account for the addition of SECINFO_NO_NAME.
SYNOPSIS
(cfh) -> (cfh)
ARGUMENT
/* CURRENT_FH: object */
void;
RESULT
struct LOOKUPP4res {
/* CURRENT_FH: directory */
nfsstat4 status;
};
DESCRIPTION
The current filehandle is assumed to refer to a regular
directory or a named attribute directory. LOOKUPP assigns the
filehandle for its parent directory to be the current
filehandle. If there is no parent directory an NFS4ERR_NOENT
error must be returned. Therefore, NFS4ERR_NOENT will be
returned by the server when the current filehandle is at the
root or top of the server's file tree.
As for LOOKUP, LOOKUPP will also cross mountpoints.
If the current filehandle is not a directory or named attribute
directory, the error NFS4ERR_NOTDIR is returned.
If the requester's security flavor does not match that
configured for the parent directory, then the server SHOULD
return NFS4ERR_WRONGSEC (a future minor revision of NFSv4 may
upgrade this to MUST) in the LOOKUPP response. However, if the
server does so, it MUST support the new SECINFO_NO_NAME
operation, so that the client can gracefully determine the
correct security flavor. See the discussion of the
SECINFO_NO_NAME operation for a description.
ERRORS
NFS4ERR_ACCESS
NFS4ERR_BADHANDLE
NFS4ERR_FHEXPIRED
NFS4ERR_IO
NFS4ERR_MOVED
NFS4ERR_NOENT
NFS4ERR_NOFILEHANDLE
NFS4ERR_NOTDIR
NFS4ERR_RESOURCE
NFS4ERR_SERVERFAULT
NFS4ERR_STALE
NFS4ERR_WRONGSEC
3. Modified Operation 33: SECINFO - Obtain Available Security
If the NFSv4 minor version is 1, then following replaces section If the NFSv4 minor version is 1, then following replaces section
14.2.31 of the NFSv4.0 specification. The SECINFO operation's "over 14.2.31 of the NFSv4.0 specification. The SECINFO operation's "over
the wire" format is not altered, but the semantics are slightly the wire" format is not altered, but the semantics are slightly
modified to account for addition of SECINFO_NO_NAME. modified to account for the addition of SECINFO_NO_NAME.
SYNOPSIS SYNOPSIS
(cfh), name -> { secinfo } (cfh), name -> { secinfo }
ARGUMENT ARGUMENT
struct SECINFO4args { struct SECINFO4args {
/* CURRENT_FH: directory */ /* CURRENT_FH: directory */
component4 name; component4 name;
}; };
skipping to change at page 5, line 36 skipping to change at page 6, line 46
handle, and the component name of the original filehandle. handle, and the component name of the original filehandle.
======================================================== ========================================================
o For LOOKUPP, the client will use SECINFO_NO_NAME { style = o For LOOKUPP, the client will use SECINFO_NO_NAME { style =
parent } and provide the filehandle with equals the parent } and provide the filehandle with equals the
filehandle originally provided to LOOKUPP. filehandle originally provided to LOOKUPP.
The READDIR operation will not directly return the The READDIR operation will not directly return the
NFS4ERR_WRONGSEC error. However, if the READDIR request NFS4ERR_WRONGSEC error. However, if the READDIR request
included a request for attributes, it is possible that the included a request for attributes, it is possible that the
READDIR request's security triple does not match that of a READDIR request's security triple did not match that of a
directory entry. If this is the case and the client has directory entry. If this is the case and the client has
requested the rdattr_error attribute, the server will return the requested the rdattr_error attribute, the server will return the
NFS4ERR_WRONGSEC error in rdattr_error for the entry. NFS4ERR_WRONGSEC error in rdattr_error for the entry.
See the section "Security Considerations" for a discussion on See the section "Security Considerations" for a discussion on
the recommendations for security flavor used by SECINFO and the recommendations for security flavor used by SECINFO and
SECINFO_NO_NAME. SECINFO_NO_NAME.
ERRORS ERRORS
NFS4ERR_ACCESS NFS4ERR_ACCESS
skipping to change at page 6, line 13 skipping to change at page 7, line 23
NFS4ERR_INVAL NFS4ERR_INVAL
NFS4ERR_MOVED NFS4ERR_MOVED
NFS4ERR_NAMETOOLONG NFS4ERR_NAMETOOLONG
NFS4ERR_NOENT NFS4ERR_NOENT
NFS4ERR_NOFILEHANDLE NFS4ERR_NOFILEHANDLE
NFS4ERR_NOTDIR NFS4ERR_NOTDIR
NFS4ERR_RESOURCE NFS4ERR_RESOURCE
NFS4ERR_SERVERFAULT NFS4ERR_SERVERFAULT
NFS4ERR_STALE NFS4ERR_STALE
3. New Operation 40: SECINFO_NO_NAME - Get Security on Unnamed Object 4. New Operation 40: SECINFO_NO_NAME - Get Security on Unnamed Object
SYNOPSIS SYNOPSIS
(cfh), secinfo_style -> { secinfo } (cfh), secinfo_style -> { secinfo }
ARGUMENT ARGUMENT
enum secinfo_style_4 { enum secinfo_style_4 {
current_fh = 0, current_fh = 0,
parent = 1 parent = 1
}; };
skipping to change at page 7, line 40 skipping to change at page 8, line 50
NFS4ERR_INVAL NFS4ERR_INVAL
NFS4ERR_MOVED NFS4ERR_MOVED
NFS4ERR_NAMETOOLONG NFS4ERR_NAMETOOLONG
NFS4ERR_NOENT NFS4ERR_NOENT
NFS4ERR_NOFILEHANDLE NFS4ERR_NOFILEHANDLE
NFS4ERR_NOTDIR NFS4ERR_NOTDIR
NFS4ERR_RESOURCE NFS4ERR_RESOURCE
NFS4ERR_SERVERFAULT NFS4ERR_SERVERFAULT
NFS4ERR_STALE NFS4ERR_STALE
4. Clarification of Security Negotiation in NFSv4.1 5. Clarification of Security Negotiation in NFSv4.1
This section attempts to clarify NFSv4.1 security negotiation issues. This section attempts to clarify NFSv4.1 security negotiation issues.
Unless noted otherwise, for any mention of PUTFH in this section, the Unless noted otherwise, for any mention of PUTFH in this section, the
reader should interpret it as applying to PUTROOTFH and PUTPUBFH in reader should interpret it as applying to PUTROOTFH and PUTPUBFH in
addition to PUTFH. addition to PUTFH.
4.1. PUTFH + LOOKUP 5.1. PUTFH + LOOKUP
The server implementation may decide whether to impose any The server implementation may decide whether to impose any
restrictions on export security administration. There are at least restrictions on export security administration. There are at least
three approaches (Sc is the flavor set of the child export, Sp that three approaches (Sc is the flavor set of the child export, Sp that
of the parent), of the parent),
a. Sc <= Sp (<= for subset) a. Sc <= Sp (<= for subset)
b. Sc ^ Sp != {} (^ for intersection, {} for the empty set) b. Sc ^ Sp != {} (^ for intersection, {} for the empty set)
c. free form c. free form
To support b (when client chooses a flavor that is not a member of To support b (when client chooses a flavor that is not a member of
Sp) and c, PUTFH must NOT return NFS4ERR_WRONGSEC in case of security Sp) and c, PUTFH must NOT return NFS4ERR_WRONGSEC in case of security
mismatch. Instead, it should be returned from the LOOKUP that mismatch. Instead, it should be returned from the LOOKUP that
follows. follows.
Since the above guideline does not contradict a, it should be Since the above guideline does not contradict a, it should be
followed in general. followed in general.
4.2. PUTFH + LOOKUPP 5.2. PUTFH + LOOKUPP
Since SECINFO only works its way down, there is no way LOOKUPP can Since SECINFO only works its way down, there is no way LOOKUPP can
return NFS4ERR_WRONGSEC without the server implementing return NFS4ERR_WRONGSEC without the server implementing
SECINFO_NO_NAME. SECINFO_NO_NAME solves this issue because via style SECINFO_NO_NAME. SECINFO_NO_NAME solves this issue because via style
"parent", it works in the opposite direction as SECINFO (component "parent", it works in the opposite direction as SECINFO (component
name is implicit in this case). name is implicit in this case).
4.3. PUTFH + SECINFO 5.3. PUTFH + SECINFO
This case should be treated specially. This case should be treated specially.
A security sensitive client should be allowed to choose a strong A security sensitive client should be allowed to choose a strong
flavor when querying a server to determine a file object's permitted flavor when querying a server to determine a file object's permitted
security flavors. The security flavor chosen by the client does not security flavors. The security flavor chosen by the client does not
have to be included in the flavor list of the export. Of course the have to be included in the flavor list of the export. Of course the
server has to be configured for whatever flavor the client selects, server has to be configured for whatever flavor the client selects,
otherwise the request will fail at RPC authentication. otherwise the request will fail at RPC authentication.
In theory, there is no connection between the security flavor used by In theory, there is no connection between the security flavor used by
SECINFO and those supported by the export. But in practice, the SECINFO and those supported by the export. But in practice, the
client may start looking for strong flavors from those supported by client may start looking for strong flavors from those supported by
the export, followed by those in the mandatory set. the export, followed by those in the mandatory set.
4.4. PUTFH + Anything Else 5.4. PUTFH + Anything Else
PUTFH must return NFS4ERR_WRONGSEC in case of security mismatch. This PUTFH must return NFS4ERR_WRONGSEC in case of security mismatch. This
is the most straightforward approach without having to add is the most straightforward approach without having to add
NFS4ERR_WRONGSEC to every other operations. NFS4ERR_WRONGSEC to every other operations.
PUTFH + SECINFO_NO_NAME (style "current_fh") is needed for the client PUTFH + SECINFO_NO_NAME (style "current_fh") is needed for the client
to recover from NFS4ERR_WRONGSEC. to recover from NFS4ERR_WRONGSEC.
5. RPC Definition File Changes 6. RPC Definition File Changes
/* /*
* Copyright (C) The Internet Society (2003) * Copyright (C) The Internet Society (2004)
* All Rights Reserved. * All Rights Reserved.
*/ */
/* /*
* nfs41_prot.x * nfs41_prot.x
*/ */
%/* $Id: nfs41_prot.x,v 1.1 2003/02/23 05:10:53 mre Exp $ */ %/* $Id: nfs41_prot.x,v 1.2 2004/06/18 23:19:28 mre Exp $ */
/* new operation, SECINFO_NO_NAME */ /* new operation, SECINFO_NO_NAME */
enum secinfo_style_4 { enum secinfo_style_4 {
current_fh = 0, current_fh = 0,
parent = 1 parent = 1
}; };
typedef secinfo_style_4 SECINFO_NO_NAME4args; typedef secinfo_style_4 SECINFO_NO_NAME4args;
typedef SECINFO4res SECINFO_NO_NAME4res; typedef SECINFO4res SECINFO_NO_NAME4res;
skipping to change at page 12, line 29 skipping to change at page 13, line 38
uint32_t minorversion; /* == 1 !!! */ uint32_t minorversion; /* == 1 !!! */
nfs_argop4 argarray<>; nfs_argop4 argarray<>;
}; };
struct COMPOUND4res { struct COMPOUND4res {
nfsstat4 status; nfsstat4 status;
utf8str_cs tag; utf8str_cs tag;
nfs_resop4 resarray<>; nfs_resop4 resarray<>;
}; };
6. Security Considerations 7. Security Considerations
The security considerations of NFSv4.0 apply to NFSv4.1, with the The security considerations of NFSv4.0 apply to NFSv4.1, with the
proviso that security considerations of SECINFO apply to the new proviso that security considerations of SECINFO apply to the new
operation, SECINFO_NO_NAME. operation, SECINFO_NO_NAME.
7. IANA Considerations 8. IANA Considerations
The IANA considerations of NFSv4.0 apply to NFSv4.1. The IANA considerations of NFSv4.0 apply to NFSv4.1.
8. Acknowledgements 9. Acknowledgements
The basis for the text in this document comes from the NFSv4.0 The basis for the text in this document comes from the NFSv4.0
specification as edited by Spencer Shepler. Peng Dai wrote the specification as edited by Spencer Shepler. Peng Dai wrote the
"Clarification of Security Negotiation in NFSv4.1" section. Sergey "Clarification of Security Negotiation in NFSv4.1" section. Sergey
Klyushin contributed to the discussion that led to this document. Klyushin contributed to the discussion that led to this document.
Mike Eisler proposed the SECINFO_NO_NAME operation to address the Mike Eisler proposed the SECINFO_NO_NAME operation to address the
issues Sergey and Peng brought to the nfsv4 working group's issues Sergey and Peng brought to the nfsv4 working group's
attention. attention. Carl Burnett reviewed an earlier draft of this document
which resulted in substantial improvements.
9. Normative References 10. Normative References
[RFC3530] [RFC3530]
S. Shepler, B. Callaghan, D. Robinson, R. Thurlow, C. Beame, M. S. Shepler, B. Callaghan, D. Robinson, R. Thurlow, C. Beame, M.
Eisler, D. Noveck, Internet RFC3530, "NFS version 4 Protocol", Eisler, D. Noveck, Internet RFC3530, "NFS version 4 Protocol",
April, 2003. April, 2003.
[RFC1831] [RFC1831]
R. Srinivasan, Internet RFC1831, "RPC: Remote Procedure Call R. Srinivasan, Internet RFC1831, "RPC: Remote Procedure Call
Protocol Specification Version 2", August, 1995. Protocol Specification Version 2", August, 1995.
skipping to change at page 13, line 24 skipping to change at page 14, line 33
Program Interface Version 2, Update 1", January, 2000. Program Interface Version 2, Update 1", January, 2000.
[RFC2203] [RFC2203]
M. Eisler, A. Chiu, L. Ling, Internet RFC2203, "RPCSEC_GSS M. Eisler, A. Chiu, L. Ling, Internet RFC2203, "RPCSEC_GSS
Protocol Specification", September, 1997. Protocol Specification", September, 1997.
[RFC1832] [RFC1832]
R. Srinivasan, Internet RFC1832, "XDR: External Data R. Srinivasan, Internet RFC1832, "XDR: External Data
Representation Standard", August, 1995. Representation Standard", August, 1995.
10. Informative References 11. Informative References
None. None.
11. Editor's Address 12. Editor's Address
Mike Eisler Mike Eisler
5765 Chase Point Circle 5765 Chase Point Circle
Colorado Springs, CO 80919 Colorado Springs, CO 80919
USA USA
Phone: 719-599-9026 Phone: 719-599-9026
EMail: mike@eisler.com EMail: mike@eisler.com
12. IPR Notices Comments on this document should be sent to the NFSv4 working group:
nfsv4@ietf.org
13. IPR Notices
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication and any assurances of claims of rights made available for publication and any assurances of
skipping to change at page 14, line 11 skipping to change at page 15, line 27
obtain a general license or permission for the use of such obtain a general license or permission for the use of such
proprietary rights by implementors or users of this specification can proprietary rights by implementors or users of this specification can
be obtained from the IETF Secretariat. be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive this standard. Please address the information to the IETF Executive
Director. Director.
13. Copyright Notice 14. Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be Copyright (C) The Internet Society (2004). This document is subject
revoked by the Internet Society or its successors or assigns. to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
This document and the information contained herein is provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
 End of changes. 

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