diff --git a/doc/standardisation/draft-ietf-cat-kerberos-set-passwd-06.txt b/doc/standardisation/draft-ietf-cat-kerberos-set-passwd-06.txt new file mode 100644 index 000000000..b15c8284d --- /dev/null +++ b/doc/standardisation/draft-ietf-cat-kerberos-set-passwd-06.txt @@ -0,0 +1,809 @@ + + + + + + +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 + + + + + +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] +