diff options
Diffstat (limited to 'doc/standardisation/draft-ietf-cat-kerberos-set-passwd-06.txt')
| -rw-r--r-- | doc/standardisation/draft-ietf-cat-kerberos-set-passwd-06.txt | 809 |
1 files changed, 0 insertions, 809 deletions
diff --git a/doc/standardisation/draft-ietf-cat-kerberos-set-passwd-06.txt b/doc/standardisation/draft-ietf-cat-kerberos-set-passwd-06.txt deleted file mode 100644 index b15c8284d..000000000 --- a/doc/standardisation/draft-ietf-cat-kerberos-set-passwd-06.txt +++ /dev/null @@ -1,809 +0,0 @@ - - - - - - -Network Working Group Jonathan Trostle -INTERNET-DRAFT Cisco Systems -Category: Standards Track Mike Swift - University of WA - John Brezak - Microsoft - Bill Gossman - Cisco Systems - - - Kerberos Set/Change Password: Version 2 - <draft-ietf-cat-kerberos-set-passwd-06.txt> - - - - -Status of this Memo - - This document is an Internet-Draft and is in full conformance with - all provisions of Section 10 of RFC2026 [6]. - - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF), its areas, and its working groups. Note that - other groups may also distribute working documents as Internet- - Drafts. - - Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - time. It is inappropriate to use Internet- Drafts as reference - material or to cite them other than as "work in progress." - - The list of current Internet-Drafts can be accessed at - http://www.ietf.org/ietf/1id-abstracts.txt - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html. - - This draft expires on December 31st, 2001. Please send comments to - the authors. - -1. Abstract - - This proposal specifies a Kerberos (RFC 1510 [3]) change/set password - protocol and a Kerberos change/set key protocol. The protocol - consists of a single request and reply message. The request message - includes both AP-REQ and KRB-PRIV submessages; the new password is - contained in the KRB-PRIV submessage which is encrypted in the - subsession key from the AP-REQ. The original Kerberos change password - protocol did not allow for an administrator to set a password for a - new user. This functionality is useful in some environments, and this - proposal allows password setting as well as password changing. The - protocol includes fields in the request message to indicate the - principal which is having its password set. We also extend the - set/change protocol to allow a client to send a sequence of keys to - - - -Trostle, Swift, Brezak, Gossman [Page 1] - -INTERNET DRAFT June 2001 Expires December 2001 - - - the KDC instead of a cleartext password. If in the cleartext password - case, the cleartext password fails to satisfy password policy, the - server should use the result code KRB5_KPASSWD_POLICY_REJECT. - -2. Conventions used in this document - - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this - document are to be interpreted as described in RFC2119 [7]. - -3. Definitions from RFC 1510 - - We include some of the relevant ASN.1 definitions from RFC 1510 in - this section. - - Realm ::= GeneralString - - PrincipalName ::= SEQUENCE { - name-type[0] INTEGER, - name-string[1] SEQUENCE OF GeneralString - } - - KerberosTime ::= GeneralizedTime - -- Specifying UTC time zone (Z) - - HostAddress ::= SEQUENCE { - addr-type[0] INTEGER, - address[1] OCTET STRING - } - - EncryptedData ::= SEQUENCE { - etype[0] INTEGER, -- EncryptionType - kvno[1] INTEGER OPTIONAL, - cipher[2] OCTET STRING -- ciphertext - } - - EncryptionKey ::= SEQUENCE { - keytype[0] INTEGER, - keyvalue[1] OCTET STRING - } - - Checksum ::= SEQUENCE { - cksumtype[0] INTEGER, - checksum[1] OCTET STRING - } - - - AP-REQ ::= [APPLICATION 14] SEQUENCE { - pvno [0] INTEGER, -- indicates Version 5 - msg-type [1] INTEGER, -- indicates KRB_AP_REQ - ap-options[2] APOptions, - ticket[3] Ticket, - authenticator[4] EncryptedData - } - - - -Trostle, Swift, Brezak, Gossman [Page 2] - -INTERNET DRAFT June 2001 Expires December 2001 - - - APOptions ::= BIT STRING { - - reserved (0), - use-session-key (1), - mutual-required (2) - } - - Ticket ::= [APPLICATION 1] SEQUENCE { - tkt-vno [0] INTEGER, -- indicates Version 5 - realm [1] Realm, - sname [2] PrincipalName, - enc-part [3] EncryptedData - } - - - -- Encrypted part of ticket - EncTicketPart ::= [APPLICATION 3] SEQUENCE { - flags[0] TicketFlags, - key[1] EncryptionKey, - crealm[2] Realm, - cname[3] PrincipalName, - transited[4] TransitedEncoding, - authtime[5] KerberosTime, - starttime[6] KerberosTime OPTIONAL, - endtime[7] KerberosTime, - renew-till[8] KerberosTime OPTIONAL, - caddr[9] HostAddresses OPTIONAL, - authorization-data[10] AuthorizationData OPTIONAL - } - - -- Unencrypted authenticator - Authenticator ::= [APPLICATION 2] SEQUENCE { - authenticator-vno[0] INTEGER, - crealm[1] Realm, - cname[2] PrincipalName, - cksum[3] Checksum OPTIONAL, - cusec[4] INTEGER, - ctime[5] KerberosTime, - subkey[6] EncryptionKey OPTIONAL, - seq-number[7] INTEGER OPTIONAL, - authorization-data[8] AuthorizationData OPTIONAL - } - - AP-REP ::= [APPLICATION 15] SEQUENCE { - pvno [0] INTEGER, -- represents Kerberos V5 - msg-type [1] INTEGER, -- represents KRB_AP_REP - enc-part [2] EncryptedData - } - - EncAPRepPart ::= [APPLICATION 27] SEQUENCE { - ctime [0] KerberosTime, - cusec [1] INTEGER, - subkey [2] EncryptionKey OPTIONAL, - seq-number [3] INTEGER OPTIONAL - - - -Trostle, Swift, Brezak, Gossman [Page 3] - -INTERNET DRAFT June 2001 Expires December 2001 - - - } - - Here is the syntax of the KRB-ERROR message: - - KRB-ERROR ::= [APPLICATION 30] SEQUENCE { - pvno[0] INTEGER, - msg-type[1] INTEGER, - ctime[2] KerberosTime OPTIONAL, - cusec[3] INTEGER OPTIONAL, - stime[4] KerberosTime, - susec[5] INTEGER, - error-code[6] INTEGER, - crealm[7] Realm OPTIONAL, - cname[8] PrincipalName OPTIONAL, - realm[9] Realm, -- Correct realm - sname[10] PrincipalName, -- Correct name - e-text[11] GeneralString OPTIONAL, - e-data[12] OCTET STRING OPTIONAL - } - - The KRB-PRIV message is used to send the request and reply data: - - KRB-PRIV ::= [APPLICATION 21] SEQUENCE { - pvno[0] INTEGER, - msg-type[1] INTEGER, - enc-part[3] EncryptedData - } - - EncKrbPrivPart ::= [APPLICATION 28] SEQUENCE { - user-data[0] OCTET STRING, - timestamp[1] KerberosTime OPTIONAL, - usec[2] INTEGER OPTIONAL, - seq-number[3] INTEGER OPTIONAL, - s-address[4] HostAddress, - -- sender's addr - r-address[5] HostAddress OPTIONAL - -- recip's addr - } - - -4. The Protocol - - The service SHOULD accept requests on UDP port 464 and TCP port 464 - as well. Use of other ports can significantly increase the complexity - and size of IPSEC policy rulesets in organizations that have IPSEC - capable nodes. - - The protocol consists of a single request message followed by a - single reply message. For UDP transport, each message must be fully - contained in a single UDP packet. - - For TCP transport, there is a 4 octet header in network byte order - that precedes the message and specifies the length of the message. - This requirement is consistent with the TCP transport header in - - - -Trostle, Swift, Brezak, Gossman [Page 4] - -INTERNET DRAFT June 2001 Expires December 2001 - - - 1510bis. - - - - Request Message - - 0 1 2 3 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | message length | protocol version number | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | AP-REQ length | AP-REQ data / - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - / KRB-PRIV message / - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - All 16 bit fields are in network byte order. - - message length field: contains the number of bytes in the message - including this field. - - protocol version number: contains the hex constant 0x0002 (network - byte order). - - AP-REQ length: length of AP-REQ data, in bytes. If the length is - zero, then the last field contains a KRB-ERROR message instead of a - KRB-PRIV message. - - AP-REQ data: (see [3]) For a change password/key request, the AP-REQ - message service ticket sname, srealm principal identifier is - kadmin/changepw@REALM where REALM is the realm of the change password - service. The same applies to a set password/key request except the - principal identifier is kadmin/setpw@REALM. The authenticator in the - AP-REQ MUST contain a subsession key (which will be used to encrypt - the KRB-PRIV user data field - see below). The KDC may have stronger - pseudorandom generating capability then the clients; thus, the client - SHOULD use the session key as an input (along with additional locally - pseudorandom generated bits) into the generation of the subsession - key. To enable setting of passwords/keys, it is not required that the - initial flag be set in the Kerberos service ticket. The initial flag - is required for change requests, but not for set requests. We have - the following definitions: - - old passwd initial flag target principal can be - in request? required? distinct from - authenticating principal? - - change password: yes yes no - - set password: no policy (*) yes - - set key: no policy (*) yes - - change key: no yes no - - - -Trostle, Swift, Brezak, Gossman [Page 5] - -INTERNET DRAFT June 2001 Expires December 2001 - - - policy (*): implementations SHOULD allow administrators to set the - initial flag required for set requests policy to either yes or no. - Clients MUST be able to retry set requests that fail due to error 7 - (initial flag required) with an initial ticket. Clients SHOULD NOT - cache service tickets targetted at kadmin/changepw. - - KRB-PRIV message (see [3]) This KRB-PRIV message must be encrypted - using the subsession key from the authenticator in the AP-REQ. The - authenticator MUST contain a subsession key. The timestamp and usec - fields of the KRB-PRIV message MUST be present, and the data values - MUST be copies of the same data values from the authenticator. The - recipient should ignore the sender address field in the KRB-PRIV - message. - - The user-data component of the message contains the DER encoding of - the ChangePasswdData ASN.1 type described below: - - ChangePasswdData ::= SEQUENCE { - passwds [0] PasswordSequence OPTIONAL, - keys [1] KeySequences OPTIONAL, - -- exactly one of the above two will be - -- present, else KRB5_KPASSWD_MALFORMED - -- error will be returned by the server. - targname[2] PrincipalName OPTIONAL, - -- only present in set password/key: the - -- principal which will have its password - -- or keys set. Not present in a set request - -- if the client principal from the ticket is - -- the principal having its passwords or keys - -- set. - targrealm[3] Realm OPTIONAL, - -- only present in set password/key: the realm - -- for the principal which will have its - -- password or keys set. Not present in a set - -- request if the client principal from the - -- ticket is the principal having its - -- passwords or keys set. - flags[4] RequestFlags OPTIONAL - -- 32 bit string - } - - KeySequences ::= SEQUENCE (SIZE (1..MAX)) OF KeySequence - - KeySequence ::= SEQUENCE { - key[0] EncryptionKey, - salt[1] OCTET STRING OPTIONAL, - -- depends on enc type, not currently used - salt-type[2] INTEGER OPTIONAL - -- depends on enc type, not currently used - } - - PasswordSequence ::= SEQUENCE { - newpasswd[0] OCTET STRING, - oldpasswd[1] OCTET STRING OPTIONAL - - - -Trostle, Swift, Brezak, Gossman [Page 6] - -INTERNET DRAFT June 2001 Expires December 2001 - - - -- oldpasswd always present for change - -- password but not present for set - -- password, set key, or change key - -- NOTE: the passwords are UTF8 strings. - } - - RequestFlags ::= BIT STRING (SIZE (32..MAX)) - -- reserved(0) - -- request-srv-gen-keys(1) - -- only in change/set keys - -- if the client desires - -- server to contribute to - -- keys; - -- server will return keys - - - The server must verify the AP-REQ message, check whether the client - principal in the ticket is authorized to set/change the password/keys - (either for that principal, or for the principal in the targname - field if present), and decrypt the new password/keys. The server also - checks whether the initial flag is required for this request, - replying with status 0x0007 if it is not set and should be. An - authorization failure is cause to respond with status 0x0005. For - forward compatibility, the server should be prepared to ignore fields - after targrealm in the structure that it does not understand. - - If the passwds field is present, it contains the new cleartext - password (with the old cleartext password for a change password - operation). Otherwise the keys field is present, and it contains a - sequence of encryption keys. - - In the cleartext password case, if the old password is sent in the - request, the request MUST be a change password request. If the old - password is not present in the request, the request MUST be a set - password request. The server should apply policy checks to the old - and new password after verifying that the old password is valid. The - server can check validity by obtaining a key from the old password - with a keytype that is present in the KDC database for the user and - comparing the keys for equality. The server then generates the - appropriate keytypes from the password and stores them in the KDC - database. If all goes well, status 0x0000 is returned to the client - in the reply message (see below). For a change password operation, - the initial flag in the service ticket MUST be set. - - In the key sequence case, the sequence of keys is sent to the change - or set password service (kadmin/changepw or kadmin/setpw - respectively). For a principal that can act as a server, its - preferred keytype should be sent as the first key in the sequence, - but the KDC is not required to honor this preference. Application - servers SHOULD use the key sequence option for changing/setting their - keys. The change/set password services should check that all keys are - in the proper format, returning the KRB5_KPASSWD_MALFORMED error - otherwise. - - - - -Trostle, Swift, Brezak, Gossman [Page 7] - -INTERNET DRAFT June 2001 Expires December 2001 - - - For change/set key, the request message may include the request flags - bit string with the request-srv-gen-keys bit set. In this case, the - client is requesting that the server add entropy to its keys in the - KeySequences field. When using this option, the client SHOULD attempt - to generate pseudorandom keys with as much entropy as possible in its - request. The server will return the final key sequence in a - KeySequences structure in the edata of the reply message. The server - does not store any of the new keys at this point. The client MUST - make a subsequent change/set key request without the request-srv- - gen-keys bit; if the server returns KRB5_KPASSWD_SUCCESS for this - second request, then the new keys have been written into the - database. A conformant server MUST support this option. - - - - - - - - Reply Message - - 0 1 2 3 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | message length | protocol version number | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | AP-REP length | AP-REP data / - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - / KRB-PRIV message / - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - All 16 bit fields are in network byte order. - - message length field: contains the number of bytes in the message - including this field. - - protocol version number: contains the hex constant 0x0002 (network - byte order). (The reply message has the same format as in the - original Kerberos change password protocol). - - AP-REP length: length of AP-REP data, in bytes. If the length is - zero, then the last field contains a KRB-ERROR message instead of a - KRB-PRIV message. An implementation should check this field to - determine whether a KRB-ERROR message or KRB-PRIV message has been - returned. - - AP-REP data: the AP-REP is the response to the AP-REQ in the request - packet. The subkey MUST be present in the AP-REP message. - - KRB-PRIV message: This KRB-PRIV message must be encrypted using the - subkey from the AP-REP message. The client should ignore the sender - address (the server's address) in the KRB-PRIV message. Reflection - attacks are prevented since the subkey is used to encrypt the user- - data field of the KRB-PRIV message. The timestamp and usec fields of - - - -Trostle, Swift, Brezak, Gossman [Page 8] - -INTERNET DRAFT June 2001 Expires December 2001 - - - the KRB-PRIV message MUST be present, and the data values MUST be - copies of the same data values from the AP-REP message. - - The server will respond with a KRB-PRIV message unless it cannot - validate the client AP-REQ or KRB-PRIV message, in which case it will - respond with a KRB-ERROR message. - - The user-data component of the KRB-PRIV message, or e-data component - of the KRB-ERROR message, must consist of the following data. - - 0 1 2 3 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | result code | key version (only on success) | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | result string length | result string / - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | edata / - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - result code (16 bits) (result codes 0-4 are the same as in the - original Kerberos change password protocol): - - The result code must have one of the following values (network - byte order): - - KRB5_KPASSWD_SUCCESS 0 request succeeds (This - value is not allowed in a - KRB-ERROR message) - - KRB5_KPASSWD_MALFORMED 1 request fails due to being - malformed - - KRB5_KPASSWD_HARDERROR 2 request fails due to "hard" - error in processing the - request (for example, there - is a resource or other - problem causing the request - to fail) - - KRB5_KPASSWD_AUTHERROR 3 request fails due to an - error in authentication - processing - - KRB5_KPASSWD_SOFTERROR 4 request fails due to a soft - error in processing the - request - - KRB5_KPASSWD_ACCESSDENIED 5 requestor not authorized - - KRB5_KPASSWD_BAD_VERSION 6 protocol version unsupported - - KRB5_KPASSWD_INITIALFLAG_NEEDED 7 initial flag required - - - - -Trostle, Swift, Brezak, Gossman [Page 9] - -INTERNET DRAFT June 2001 Expires December 2001 - - - KRB5_KPASSWD_POLICY_REJECT 8 new cleartext password fails - policy; the result string - should include a text - message to be presented to - the user. - - KRB5_KPASSWD_WRONG_SRV 9 policy failure: the client - sent change/set key and - should have sent change/set - passwd, or vice-versa. - - KRB5_KPASSWD_BAD_PRINCIPAL 10 target principal does not - exist (only in response to - a set password or set key - request). - - KRB5_KPASSWD_ETYPE_NOSUPP 11 the request contains a key sequence - containing at least one etype that - is not supported by the KDC. The - response edata contains an ASN.1 - DER encoded PKERB-ETYPE-INFO type - that specifies the etypes that the - KDC supports: - - KERB-ETYPE-INFO-ENTRY :: = SEQUENCE - { - encryption-type[0] INTEGER, - salt[1] OCTET STRING - OPTIONAL -- not sent, client - -- may ignore if - -- sent - } - - PKERB-ETYPE-INFO ::= SEQUENCE OF - KERB-ETYPE-INFO-ENTRY - - The client should retry the request - using only etypes (keytypes) that - are contained within the - PKERB-ETYPE-INFO structure in the - previous response. - - KRB5_KPASSWD_ETYPE_SRVGENKEYS 12 See the following paragraph. - - - The KRB5_KPASSWD_ETYPE_SRVGENKEYS result code is returned when - the request has the request-srv-gen-keys flag set and the - server is returning the KeySequences structure defined above in - the edata field of the reply. The server returns one key sequence - structure of the same keytype for each key sequence structure in - the client request, unless it does not support one of the - keytypes (or etypes). In that case, it returns error - KRB5_KPASSWD_ETYPE_NOSUPP as discussed above. The server MUST - add keylength number of bits of entropy to each key, where - - - -Trostle, Swift, Brezak, Gossman [Page 10] - -INTERNET DRAFT June 2001 Expires December 2001 - - - keylength is the number of actual key bits in the key (minus - any parity or non-entropy contributing bits). The assumption - here is that the client may have added insufficient entropy - to the request keys. The server SHOULD use the client key from - each KeySequence structure as input into the final keyvalue for - the returned key. The client MUST make another request after - receiving a reply with this status, since no keys have been - written into the database. - - 0xFFFF is returned if the request fails for some other reason. - The client must interpret any non-zero result code as a failure. - - key version (16 bits - optional): - Present if and only if the result - code is KRB5_KPASSWD_SUCCESS. This contains the key version of - the new key(s). - - result string length (16 bits): - Gives the length of the following result string field, in bytes. - If the result string is not present, the length is zero. - - result string (optional): - This field is a UTF-8 encoded string which can be displayed - to the user. Specific reasons for a password set/change policy - failure is one possible use for this string. - - edata (optional): - Used to convey additional information as defined by the - result code. - -5. Acknowledgements - - The authors thank Ken Raeburn, Tom Yu, Martin Rex, Sam Hartman, Tony - Andrea, Nicolas Williams, and other participants from the IETF - Kerberos Working Group for their input to the document. - -6. Security Considerations - - Password policies should be enforced to make sure that users do not - pick passwords (for change password/key) that are vulnerable to brute - force password guessing attacks. - -7. References - - [1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP - 9, RFC 2026, October 1996. - - [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement - Levels", BCP 14, RFC 2119, March 1997 - - [3] J. Kohl, C. Neuman. The Kerberos Network Authentication - Service (V5), Request for Comments 1510. - - - - - -Trostle, Swift, Brezak, Gossman [Page 11] - -INTERNET DRAFT June 2001 Expires December 2001 - - -8. Expiration Date - - This draft expires on December 31st, 2001. - -9. Authors' Addresses - - Jonathan Trostle - Cisco Systems - 170 W. Tasman Dr. - San Jose, CA 95134 - Email: jtrostle@cisco.com - - Mike Swift - University of Washington - Seattle, WA - Email: mikesw@cs.washington.edu - - John Brezak - Microsoft - 1 Microsoft Way - Redmond, WA 98052 - Email: jbrezak@microsoft.com - - Bill Gossman - Cisco Systems - 500 108th Ave. NE, Suite 500 - Bellevue, WA 98004 - Email: bgossman@cisco.com - -10. Full Copyright Statement - - Copyright (C) The Internet Society (2001). 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 implmentation 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 - revoked by the Internet Society or its successors or assigns. - - This document and the information contained herein is provided on an - "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING - TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING - BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION - - - -Trostle, Swift, Brezak, Gossman [Page 12] - -INTERNET DRAFT June 2001 Expires December 2001 - - - HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF - MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Trostle, Swift, Brezak, Gossman [Page 13] - |