idnits 2.17.1 draft-abid-eap-osfr-00.txt: -(94): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(314): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(374): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1.a on line 21. -- Found old boilerplate from RFC 3978, Section 5.5 on line 574. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ( - It does however have an RFC 2026 Section 10.4(A) Disclaimer.) ** The document seems to lack an RFC 3979 Section 5, para. 2 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 3 IPR Disclosure Invitation -- however, there's a paragraph with a matching beginning. Boilerplate error? ( - It does however have an RFC 2026 Section 10.4(B) IPR Disclosure Invitation.) ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There are 7 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 15 instances of too long lines in the document, the longest one being 3 characters in excess of 72. ** There is 1 instance of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 11, 2005) is 6857 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC 2631' is mentioned on line 471, but not defined == Unused Reference: 'RFC2119' is defined on line 497, but no explicit reference was found in the text == Outdated reference: A later version (-09) exists of draft-ietf-eap-netsel-problem-02 ** Downref: Normative reference to an Informational draft: draft-ietf-eap-netsel-problem (ref. 'ARK04') -- Possible downref: Non-RFC (?) normative reference: ref. 'WIR03' -- Unexpected draft version: The latest known version of draft-adrangi-eap-network-discovery-and-selection is -01, but you're referring to -13. -- Possible downref: Normative reference to a draft: ref. 'ADR05' Summary: 13 errors (**), 0 flaws (~~), 6 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group M. Abid 2 Internet-Draft INRIA 3 Expires: Juanuary 12, 2006 H. Afifi 4 Int 5 F. Kamoun 6 CRISTAL 7 N. Golmie 8 NIST 9 July 11, 2005 11 OSFR (Optimized network Selection for Fast Roaming) 12 draft-abid-eap-osfr-00 14 Status of this Memo 16 This document is an Internet-Draft and is subject to all provisions 17 of section 3 of RFC 3667. By submitting this Internet-Draft, each 18 author represents that any applicable patent or other IPR claims of 19 which he or she is aware have been or will be disclosed, and any of 20 which he or she becomes aware will be disclosed, in accordance with 21 Section 6 of BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as 26 Internet-Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/1id-abstracts.txt. 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html. 39 This Internet-Draft will expire on Juanuary 12, 2006. 41 Copyright Notice 43 Copyright (C) The Internet Society (2005). 45 Abstract 47 In a public WLAN hotspot, we need to have an easy and secure way to 48 authenticate users. We have to find also mobility solutions, given 49 by providers, to perform well the roaming. A roaming mobile terminal 50 MT may be within radio range of more than one access point AP. 51 Therefore, we need to make an intelligent network selection decision 52 after receiving some roaming information. Currently, the information 53 is typically provisioned on the MTs as static roaming tables. But, 54 this approach is not scalable when there is a large number of access 55 points. 57 In this draft, we propose our solution called OSFR, Optimized Network 58 Selection for Fast Roaming to improve association speed and 59 scalability. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 1.2 Applicability . . . . . . . . . . . . . . . . . . . . . . . . . 4 66 2. Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 67 3. Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 68 4. Packet Format . . . . . . . . . . . . . . . . . . . . . . . . . 8 69 4.1 Beacon . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 70 4.2 Probe Request . . . . . . . . . . . . . . . . . . . . . . . . . 9 71 4.3 Probe Response . . . . . . . . . . . . . . . . . . . . . . . 9 72 4.4 Authentication Request . . . . . . . . . . . . . . . . . . . . 9 73 4.5 Authentication Response or Challenge Text . . . . . . . . . . 10 74 4.6 (Re)Association Request . . . . . . . . . . . . . . . . . . . 10 75 5. Security Considerations . . . . . . . . . . . . . . . . . . . 12 76 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 77 References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 14 79 Intellectual Property and Copyright Statements . . . . . . . . 16 81 1. Introduction 83 In a public WLAN hotspot, a roaming MT mobile terminal may be within 84 radio range of more than one access point (AP). Therefore, we need 85 to make an intelligent network selection decision after receiving 86 some roaming information. Currently, the information is typically 87 provisioned on the MTs as static roaming tables. But, this approach 88 is not scalable when there are a large number of access points. 90 In this draft, we propose our solution called OSFR, Optimized Network 91 Selection for Fast Roaming to improve association speed and 92 scalability. It consists in piggybacking the information in the 802.11 93 Authentication Request/Response. The main advantage of our system is 94 that we don�t need to (re)associate each time with the new AP, rather 95 associate only with the appropriate one which speeds up the connection 96 procedure and results in a seamless handover. 98 1.1 Terminology 100 AAA 102 Authentication ,Authorization and Accounting 104 NAI 106 Network Address Identifier [rfc2486bis]. 108 MT 110 Mobile Terminal 112 AP 114 The new Access Point that MT wants to associate with. 116 AAA Wlan Server 118 It is the Local Wireless LAN Server which has a list of vWISP virtual 119 WISP that it has agreements with them. 121 AAA Mediating Server 123 The mediating Server that is localized in the path between AAA Wlan 124 Server and AAA Home server. 126 AAA Home Server 128 The server which provides service for mobile node (MT has an account 129 there). 131 For clarity, we will omit AAA from the terminology. 133 1.2 Applicability 135 Our solution is really helpful in these cases described in [ARK04]: 137 o There is more than one available network attachment point, and 138 the different points may have different characteristics. 140 o The user has multiple sets of credentials. For instance, the user 141 could have one set of credentials from a public service provider 142 and another set from his company. 144 o Providers share the same infrastructure, such as wireless access 145 points. 147 The mobile terminal will need to associate with the right network, 148 so that it can reach its home server. Especially, working in public 149 places can causes high latency, especially, when the place is full 150 of clients. 152 One of the problem that all people hate is the cut of receiving 153 services. If we can not avoid it, at least, we try to reduce this 154 time needed for network discovery and selection. 156 2. Design 158 One of the important characteristics of our solution is that we want 159 to know the roaming information before getting associated with AP. We 160 also need to send the information in a secure way because we work 161 before the association and the channel isn�t secure. Our idea is 162 based on Diffie-Hellman Key exchange (D-H Key) [RFC2631] and optimized 163 to use the 802.11 Management Frames [WIR03]. 165 First of all, in Beacon frame, we add the two parameters needed to 166 generate the D-H keys. Then, in Probe Request, MT sends its public key 167 YMT and in Probe Response, AP sends its public key YAP. Now the two 168 devices can send encrypted data with D-H keys. In IEEE 802.11 169 specification, we have two kinds of authentication algorithm (Open 170 System and Shared Key). In our solution, using one of the two will not 171 cause problems because we only use Auth Request and Auth Response for 172 Open System, Auth Request and Challenge Text for Shared Key. 174 We aim to add roaming information which consists essentially in the 175 identity of the intermediary WISP needed for Network Selection. If MT 176 finds the WISP that it can reach its Home Server, it will send the 177 identity of this Mediating Server. In that case, we will use the path 178 passing by this Mediating Server in EAP session. We choose to send the 179 list of WISP in the body of Management frame because this method helps 180 us to use the maximum length for information. 182 In some solution like Adrangi, et all [ADR05], the length used will 183 be less than 1020 bytes. But when we use Management Frame body the 184 least possibility will be when we piggyback information after 185 Challenge Text and it will be 2048 bytes. 187 OSFR assumes also backward compatibility with devices that do not 188 support this technique. Let�s give now more details about how OSFR 189 performs. 191 3. Scenario 193 In this scenario, we present all possible interactions between the 194 actors. In the fellowing, we see all the message in OSFR scenario. 196 MT AP AAA WLAN AAA Mediating AAA Home 197 server Server Server 198 | | | | | 199 | /-------------| | | | 200 |/ beacon | | | | 201 |\ (p, g) | | | | 202 | \-------------| | | | 203 | | | | | 204 | (1) | | | | 205 | Probe Request | | | | 206 | + YMN | | | | 207 |------------- >| | | | 208 | | | | | 209 | (2) | | | | 210 | Probe Response| | | | 211 | +YAP | | | | 212 |< ------------ | | | | 213 | | | | | 214 | (3) | | | | 215 | Auth Request | | | | 216 | + | | | | 217 |(user@realm)D-H| | | | 218 |------------- >| | | | 219 | | | | | 220 MT AP AAA WLAN AAA Mediating AAA Home 221 server Server Server 222 | | | | | 223 | | EAP.Req | | | 224 | | (user@realm) | | | 225 | |------------- >| | | 226 | | (4) | | | 227 | | EAP.Resp | | | 228 | | (List vWISP) | | | 229 | |< ------------ | | | 230 | | | | | 231 | (5) | | | | 232 | Auth Response | | | | 233 | or | | | | 234 | Challenge Text| | | | 235 | + | | | | 236 |(List vWISP)D-H| | | | 237 |< ------------ | | | | 238 | | | | | 239 |Challenge Resp | | | | 240 |............. >| | | | 241 | | | | | 242 |Confirm Success| | | | 243 |< ............ | | | | 244 | | | | | 245 | (6a) | | | | 246 |(re)association| | | | 247 | Request | | | | 248 | + | | | | 249 |(NAI {Medaiting| | | | 250 | Server})D-H | | | | 251 |------------- >| | | | 252 | (7) | | | | 253 |(re)association| | | | 254 | Response | | | | 255 |< ------------ | | | | 256 | | | | | 257 | (8) | | | | 258 | EAP Id. Req. | | | | 259 |< -------------| | | | 260 | | | | | 261 | EAP Id. Resp. | | | | 262 |------------- >| | | | 263 | | Access Request| | | 264 | |(EAP Id. Resp.)| | | 265 | |------------- >| | | 266 | | | | | 267 MT AP AAA WLAN AAA Mediating AAA Home 268 server Server Server 270 | | | Access Request| | 271 | | |(EAP Id. Resp.)| | 272 | | |------------- >| | 273 | | | | | 274 | | | |Access Request | 275 | | | |(EAP Id. Resp.)| 276 | | | |------------- >| 277 | ... | ... | ... | ... | 278 | < EAP Authentication Methods > | 279 | ... | ... | ... | ... | 280 | | | | | 281 | EAP Success | | | | 282 |< ------------ | | | | 283 | | | | | 285 AP sends Beacon to alert the users about its presence. In our 286 solution, AP is the one who chooses the parameters (prime number 'p' 287 and base 'g') needed to generate the D-H keys. Here are all possible 288 interactions in our scenario: 290 1 When MT sends to AP a Probe Request, it piggybacks its public key 291 YMT. 293 2 AP sends Probe Response to MT and piggybacks its public key YAP. 294 After exchanging the public keys, we can begin a secure session 295 using D-H keys. Our modification will not depend on the type of 296 IEEE 802.11 Authentication. 298 3 MT sends an Authentication Request including its identity 299 user@realm encrypted with D-H key. 301 4 AP will send the identity in an EAP Request to WLAN Server. This 302 later has a list of vWISP virtual WISP. WLAN Server will send the 303 list to AP within an EAP Response. 305 5 A can be the Authentication Response "Open System" or the 306 Challenge Text "Shared Key". AP piggybacks the list (encrypted 307 with D-H key). MT needs this list to choose the "right" Mediating 308 Server to reach its Home Server. If we choose Open System, we pass 309 directly to (re)association. Otherwise, if it is Shared Key, we 310 continue to send the Challenge Response and Success Access. 312 6 Now, all depends on the list received by MT: 314 6a MT doesn�t find the right Mediating Server in the list sent 315 by AP; it will not (re)associate with AP and will seek for 316 another one. For example, MT wants a French WISP but in the 317 list there is only American WISP. 319 6b In the other case, MT sends (re)Association Request and 320 piggybacks the NAI of the Mediating Server encrypted with 321 D-H key. 323 7 AP sends (re)Association response to MT. 325 8 Now, EAP session can begin and we are sure that WLAN Server will 326 reach the Home Server using a path including the chosen Mediating 327 Server. 329 4. Packet Format 331 In this section, we introduce all the changes that we need to do in 332 the body of some Management Frames. The maximum size of the frame 333 body is 2312 bytes. We will add some new Information Elements that 334 have 3 fields: 336 +---------------+----------+--------------------+ 337 | Element ID(1) |Length(1) | Information(length)| 338 +---------------+----------+--------------------+ 340 We found in the IEEE 802.11 specification some reserved element ID 341 (7-15, 32-255). We project to use some of this element ID to add our 342 new Information Elements. The length given between () is in bytes for 343 all fields. 345 4.1 Beacon 347 We piggyback the prime 'p' and base 'g'. The length of the parameters 348 'p' and 'g' will be 1024 bits (128 bytes). In the IEEE 802.11 349 specification, the maximum length free in Beacon frame body is 334 350 bytes. We just add after TIM (Traffic Indication Map) 2 new fields 351 one for parameter 'p' and the other for 'g'. The length of each field 352 is 128 bytes. 354 P: Information Elements 356 +-----------------+---------------+--------+ 357 | Element ID(1)=7 | Length(1)=128 | p(128) | 358 +-----------------+---------------+--------+ 360 G: Information Elements 362 +-----------------+---------------+--------+ 363 | Element ID(1)=8 | Length(1)=128 | g(128) | 364 +-----------------+---------------+--------+ 366 The new beacon frame body seems like: 368 +----------------------+--------+--------+ 369 | 802.11 Beacon Fields | P(130) | G(130) | 370 +----------------------+--------+--------+ 372 4.2 Probe Request 374 In the probe request, we add the MT�s public key YMT. The later will 375 be a new element information. 377 +-----------------+---------------+--------+ 378 | Element ID(1)=9 | Length(1)=128 | y(128) | 379 +-----------------+---------------+--------+ 381 The new Probe Request frame body seems like: 383 +----------+---------------------+--------+ 384 | SSID(34) | Supported rates(10) | Y(128) | 385 +----------+---------------------+--------+ 387 4.3 Probe Response 389 It is like Probe Request but source now is AP. We have the same 390 Information Element y (Element ID=9) called YAP. The new Probe Request 391 frame body seems like: 393 +------------------------------+--------+ 394 | 802.11 Probe Response Fields | Y(128) | 395 +------------------------------+--------+ 397 4.4 Authentication Request 399 Identity is a string which identifies user (ex mail address, login). 400 The new Element Information contains the identity encrypted by D-H 401 key. The max length of Identity will be 2304 bytes. 403 +------------------+-----------+------------------+ 404 | Element ID(1)=10 | Length(1) | identity(Length) | 405 +------------------+-----------+------------------+ 407 The frame body will be: 409 +---------------------------+---------------------+ 410 |802.11 Auth Request Fields | Identity(length +2) | 411 +---------------------------+---------------------+ 413 4.5 Authentication Response or Challenge Text 415 We add a new Element Information called List (encrypted with D-H key). 417 +------------------+-----------+--------------+ 418 | Element ID(1)=11 | Length(1) | list(Length) | 419 +------------------+-----------+--------------+ 421 1 If Authentication algorithm number equals 0 (Open System), the 422 frame body will be: 424 +----------------------------+----------------+ 425 |802.11 Auth Response Fields |List(length +2) | 426 +----------------------------+----------------+ 428 Here the maximum length of List is 2304 bytes. 430 2 If Authentication algorithm number equals 1 (Shared Key), the 431 frame body will be: 433 +----------------------------+----------------+ 434 |802.11 Challenge Text Fields|List(length +2) | 435 +----------------------------+----------------+ 437 Here the maximum length of List is 2048 bytes. The 2 next frames 438 in Shared Key Authentication won�t be modified. 440 4.6 (Re)Association Request 442 Here we will add the last new Information Element NAI. It is the 443 identifier of the Mediating Server (encrypted with D-H key). The 444 maximum possible length for NAI is 2262 bytes. 446 +------------------+-----------+-------------+ 447 | Element ID(1)=12 | Length(1) | nai(Length) | 448 +------------------+-----------+-------------+ 450 1 If we have Association Request, the frame body will be: 452 +---------------------------------+----------------+ 453 |802.11 Association Request Fields|NAI(length +2) | 454 +---------------------------------+----------------+ 456 2 If we have Re-association Request, the frame body will be: 458 +-----------------------------------+----------------+ 459 |802.11 Reassociation Request Fields|NAI(length +2) | 460 +-----------------------------------+----------------+ 462 The final (re)Association response will not be changed. 464 5. Security Considerations 466 OSFR use Diffie Hellman to secure the exchange of encryted data in 467 the management level. All the security in this system is provided by 468 the secrecy of the private keying material. If either sender or 469 recipient private keys are disclosed, all messages sent or received 470 using that key are compromised. Similarly, loss of the private key 471 results in an inability to read messages sent using that key [RFC 2631]. 473 6. Acknowledgments 475 The authors would like to thank Walid Dabbous and our colleagues at 476 Planete team for their comments and suggestions. Also, we thank the 477 members of CRISTAL Laboratory. 479 References 481 [ARK04] J. Arkko and B. Aboba, "Network Discovery and Selection 482 Problem", draft-ietf-eap-netsel-problem-02, October 2004. 484 [WIR03] ANSI/IEEE Std 802.11, 1999 Edition (R2003), Wireless LAN 485 Medium Access Control (MAC) and Physical Layer (PHY) 486 Specifications. 488 [ADR05] F. Adrangi, V. Lortz, F. Bari, P. Eronen. "Identity 489 selection hints for Extensible Authentication Protocol 490 (EAP)", 491 draft-adrangi-eap-network-discovery-and-selection-13.txt, 492 May 2005. 494 [RFC2631] E. Rescorla, "Diffie-Hellman Key Agreement Method", 495 RFC 2631,June 1999. 497 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 498 Requirement Levels", BCP 14, RFC 2119, March 1997. 500 [rfc2486bis] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The 501 Network Access Identifier", 502 draft-ietf-radext-rfc2486bis-05 (work in progress), 503 July 2004. 505 Authors' Addresses 507 Mohamed Abid 508 INRIA Sophia Antipolis 509 2004 route des lucioles 510 BP 93 06902 Sophia Antipolis 511 France 513 EMail: Mohamed.Abid@sophia.inria.fr 515 Hossam Afifi 516 INT 517 9 rue, Charles Fourier 518 Evry 91011 519 FRANCE 521 Phone: +33 1 60 76 47 08 522 EMail: Hossam.Afifi@int-evry.fr 523 Farouk Kamoun 524 CRISTAL ENSI 525 Universit� de la Manouba 526 2010 527 Tunisia 529 Phone: +216 71 600 444 / +216 98 328 083 530 EMail: Farouk.kamoun@ensi.rnu.tn 532 Nada Golmie 533 NIST 534 100 Bureau Drive, Mail Stop 8920, 535 Gaithersburg, Maryland, U.S.A. 536 Phone: +1 301-975-4190 537 Mail: nada.golmie@nist.gov 538 Intellectual Property Statement 540 The IETF takes no position regarding the validity or scope of any 541 intellectual property or other rights that might be claimed to 542 pertain to the implementation or use of the technology described in 543 this document or the extent to which any license under such rights 544 might or might not be available; neither does it represent that it 545 has made any effort to identify any such rights. Information on the 546 IETF's procedures with respect to rights in standards-track and 547 standards-related documentation can be found in BCP-11. Copies of 548 claims of rights made available for publication and any assurances of 549 licenses to be made available, or the result of an attempt made to 550 obtain a general license or permission for the use of such 551 proprietary rights by implementors or users of this specification can 552 be obtained from the IETF Secretariat. 554 The IETF invites any interested party to bring to its attention any 555 copyrights, patents or patent applications, or other proprietary 556 rights which may cover technology that may be required to practice 557 this standard. Please address the information to the IETF Executive 558 Director. 560 Full Copyright Statement 562 Copyright (C) The Internet Society (2005). This document is subject to 563 the rights, licenses and restrictions contained in BCP 78, and except 564 as set forth therein, the authors retain all their rights. 566 Disclaimer of Validity 568 This document and the information contained herein are provided on an 569 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 570 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 571 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 572 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 573 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 574 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.