idnits 2.17.1 draft-tschofenig-nsis-sid-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == 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. 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 (June 2003) is 7620 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'THREATS' -- Possible downref: Non-RFC (?) normative reference: ref. 'NSIS-FW' -- Possible downref: Non-RFC (?) normative reference: ref. 'PBK' -- Possible downref: Non-RFC (?) normative reference: ref. 'WC02' -- Possible downref: Non-RFC (?) normative reference: ref. 'CASP' ** Downref: Normative reference to an Informational RFC: RFC 3521 -- Possible downref: Non-RFC (?) normative reference: ref. 'Tho02' Summary: 4 errors (**), 0 flaws (~~), 2 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NSIS 3 Internet Draft H. Tschofenig 4 Siemens 5 H. Schulzrinne 6 Columbia U. 7 R. Hancock 8 A. McDonald 9 Siemens/Roke Manor 10 X. Fu 11 Univ. Goettingen 12 Document: draft-tschofenig-nsis-sid-00.txt 13 Expires: December 2003 June 2003 15 Security Implications of the Session Identifier 16 18 Status of this Memo 20 This document is an Internet-Draft and is subject to all provisions 21 of Section 10 of RFC2026. 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 Internet- 26 Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six 29 months and may be updated, replaced, or obsoleted by other documents 30 at any 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/1id-abstracts.html 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html 39 Abstract 41 As one result of the analysis activities in the NSIS group it was 42 realized that mobility and the ability to change the flow identifier 43 causes problems with existing QoS reservations. To be able to 44 associate a signaling message with existing state an identifier 45 other than the flow identifier had to be used. Such an abstraction 46 is achieved with the session identifier which allows identification 47 of established state independently of the flow characteristics. 49 Although the introduction of a session identifier sounds simple and 50 beneficial, it introduces a problem which is subsequently referred 51 to as the session ownership problem. 53 This document describes the session ownership problem, the 54 implications for an NSIS protocol and summarizes already discussed 55 solutions. 57 Table of Contents 59 1. Introduction..................................................2 60 2. Problem Description...........................................3 61 2.1 Mobility..................................................3 62 2.2 Local Repair Case.........................................4 63 3. Solution Discussion...........................................5 64 3.1 Local solutions...........................................6 65 3.1.1 Authorization Token...................................6 66 3.1.2 Context Transfer......................................6 67 3.1.3 Centralized Entity....................................7 68 3.2 Global Solutions..........................................7 69 3.2.1 Purpose Built Key Based Approach......................7 70 3.2.2 Hash Series Based Approach............................8 71 3.2.3 Confidentiality protection of session identifier......9 72 4. Pending Issues...............................................10 73 5. Summary......................................................10 74 6. Security Considerations......................................11 75 7. Open Issues..................................................11 76 8. References...................................................11 77 Acknowledgments.................................................12 78 Author's Addresses..............................................12 80 1. Introduction 82 As one result of the analysis activities in the NSIS group it was 83 realized that mobility and the ability to change the flow identifier 84 causes problems with existing QoS reservations. To be able to 85 associate a signaling message with existing state an identifier 86 other than the flow identifier had to be used. Such an abstraction 87 is achieved with the session identifier which allows identification 88 of established state independently of the flow characteristics. 90 Although the introduction of a session identifier sounds simple and 91 beneficial, it introduces a problem which is subsequently referred 92 to as the session ownership problem. Although the problem is known 93 for a very long time (discussion took place already at the 53rd IETF 94 and even proposals for solving the problem have been mentioned) the 95 topic still has some grey spots. 97 This document describes the session ownership problem, the 98 implications for an NSIS protocol and summarizes already discussed 99 solutions. 101 2. Problem Description 103 To allow signaling messages to refer to existing state some sort of 104 identifier is required. In RSVP this identifier is based on the flow 105 identifier. 107 To support mobility and to introduce the ability to change the flow 108 identifier mid-session and mid-path an additional identifier is 109 required. Throughout this text we call this additional identifier 110 the session identifier. Section 4.5.2 of [NSIS-FW] provides a 111 description of the different identifiers used in NSIS. 113 When a NSIS node receives a signaling message then it has to check 114 whether state information already exists, or whether new state has 115 to be established. The session identifier can quickly provide 116 information whether state information is already available. 118 Some of the described problems are less problematic in non-mobile 119 environments since the first NSIS-aware router (for example the edge 120 or access router) can associate authentication state with the 121 session identifier, and hence ownership can be verified. However, if 122 we assume a mobility scenario then the movement of a 123 node makes this verification step much more difficult since each 124 NSIS-aware node along the path could possibly be forced to do this 125 verification. 127 2.1 Mobility 129 Figure 1 shows an NSIS Initiator which established state information 130 at NSIS nodes along the path as part of the signaling procedure. As 131 a result Access Router 1, Router 3 and Router 4 (and other nodes) 132 store state information including the Session Identifier SID-x. 134 Session ID(SID-x) 135 +--------+ 136 +-----------------+ Router +------------> 137 Session ID(SID-x)| | 4 | 138 +---+----+ +--------+ 139 | Router | 140 +------+ 3 +******* 141 | +---+----+ * 142 | * 143 | Session ID(SID-x) * Session ID(SID-x) 144 +---+----+ +---+----+ 145 | Access | | Access | 146 | Router | | Router | 147 | 1 | | 2 | 148 +---+----+ +---+----+ 149 | * 150 | Session ID(SID-x) * Session ID(SID-x) 151 +----+------+ +----+------+ 152 | NSIS | | Adversary | 153 | Initiator | | | 154 +-----------+ +-----------+ 156 Figure 1: Mobility Scenario 158 The Session Identifier is included in signaling messages as a 159 reference to the established state. 161 If an adversary were able to obtain the Session Identifier for 162 example by eavesdropping signaling messages it would be able to add 163 the same Session Identifier SID-x to a new a signaling message. When 164 the signaling message hits Router3 (as shown in Figure 3) then 165 existing state information can be modified. The adversary can modify 166 or delete the established reservation causing unexpected behavior 167 for the legitimate user. 169 The source of the problem is that Router 3 (cross-over router) is 170 unable to decide whether the new signaling message was initiated 171 from the owner of the session/reservation. 173 In case that this threat is not addressed an adversary can launch 174 denial of service, theft of service, and various other attacks. 176 Note that the same problem might occur at the receiver side. 178 2.2 Local Repair Case 180 In the above section an end host mobility scenario is described. 182 To make the situation more difficult it must be mentioned that not 183 only the initial signaling message originator is allowed to 184 authorize NSIS specific operations during the lifetime of an 185 established session. As part of the protocol any NSIS aware node 186 along the path (and the path might change over time) could be 187 involved in the signaling message exchange and it might be necessary 188 to provide mobility support or to trigger a local repair procedure. 189 Hence if only the initial signaling message originator is allowed to 190 trigger signaling message exchange some protocol behavior will not 191 be possible. 193 - old path - 195 +--------+ 196 | Router | 197 +....>| 2 +...+ 198 . +--------+ . cross-over 199 . . router 200 +--------+ . . +--------+ 201 | Router +..+ +.....>| Router | 202 ------>| 1 +--+ +----->| 4 +--------> 203 +--------+ | | +--------+ 204 | +--------+ | 205 +---->| Router +---+ 206 | 3 | 207 +--------+ 209 - new path - 211 Figure 2: Route Change Scenario 213 3. Solution Discussion 215 Some possible means for verification and proofing ownership of a 216 session are given below. These examples should give the reader 217 information about the current state of the discussion. 219 This section is divided into two parts: First, there is a subsection 220 which proposes so-called "local solutions". These solutions are 221 characterized by the location where this verification is done. This 222 region is typically within the same administrative domain where the 223 user is authenticated for the purpose of authorization. Note that an 224 intra-domain handover does not necessarily mean that the cross-over 225 router where the old path hits the new path is also in the same 226 administrative domain. It could be external and therefore these 227 local solutions might not be applicable. 229 So-called "global solutions" work independently of the domain where 230 the end host is currently attached. 232 Note that local does not necessarily only refer to the first 233 administrative domain. If a trust relationship with other domains 234 also exist then verification is possible at other domains as well. 236 3.1 Local solutions 238 The following solutions have one property in common which allows an 239 entity to verify that a signaling message is actually legitimate to 240 perform the indicated action: At the initial request some state is 241 created which allows subsequent requests to be associated with this 242 state. 244 The created state can either be in the network itself (e.g. at a 245 centralized entity) whereby the centralized entity needs to be 246 queried to perform verification or some information is shipped 247 around but allows local verification. 249 3.1.1 Authorization Token 251 The authorization token approach requires that an entity in the 252 network produces a token during the initial signaling message 253 exchange. This token is cryptographically protected and must be 254 verifiable by entities in the local domain. The authorization token 255 must be protected to prevent an adversary at the wireless link to 256 intercept the token and to reuse it. The authorization token allows 257 link subsequent actions to an initial authorization (e.g. by 258 including the token into the signaling message after a handover). 259 The end host only forwards the authorization token. Hence the token 260 itself does not provide authentication. 262 This solution is referred as local since the token has to be granted 263 and verified within the same domain (or within domains with a pre- 264 defined trust relationship). 266 A more sophisticated version would use a concept similar to Kerberos 267 tickets whereby the end host actively participates in the protocol 268 by showing the knowledge of the session key. As authorization 269 information the ticket could include the session identifier. 271 3.1.2 Context Transfer 273 Context Transfer is another approach the network to associate a new 274 signaling message to a previous one. The Context Transfer protocol 275 allows to move state information from one access router to another. 276 The assumption thereby is that if state was create at one particular 277 access router then the forwarded state would also allow the new 278 access router to verify the incoming signaling message. Due to the 279 transitive trust provided by hop-by-hop security protection in 280 intermediate router would trust that the signaling message have been 281 correctly verified and only the authorized entity issued the 282 signaling message. 284 A short discussion of context transfer in relationship with RSVP is 285 provided in Section 1.2.6 of [Tho02]. The same considerations are 286 also applicable to CT for NSIS. 288 3.1.3 Centralized Entity 290 Using this approach a cross-over router where the new path hits the 291 old path and where authorization is desired information inside the 292 signaling message (e.g. a token which only points to state installed 293 at the centralized entity or user credentials) could be used to 294 perform this verification. For QoS signaling the Policy Decision 295 Point would be a possible centralized entity. 297 Different to authorization token approach the token does not need to 298 be verified at an individual node itself. For the authorization 299 token approach it is necessary to provide the necessary information 300 within the token itself. In case of a central entity only a 301 reference to the stored information needs to be provided. The 302 distinction between the authorization token and this approach is 303 therefore, from an NSIS protocol point of view, marginal. A solution 304 could possible support both mechanisms easily (e.g. [RFC3521] and 305 [RFC3520]). 307 3.2 Global Solutions 309 3.2.1 Purpose Built Key Based Approach 311 This approach makes use of a cryptographic session identifier and 312 follows the idea described in [PBK]. The identifier is created as: 314 Session ID = PRF(Public Key) 316 The output of the PRF function needs to be truncated if necessary to 317 fit the length requirements of the Session ID. As a PRF function MD5 318 or SHA-1 could be used. 320 The signaling initiator would therefore create a public / private 321 key pair before starting NSIS signaling for a specific session. 323 Every time the end host roams from one location to another the 324 following information is added to the NSIS signaling message: 326 - Session ID 327 - Public Key 328 - Digital Signature of some signaling message payloads including a 329 timestamp 331 A receiving entity (e.g. cross-over router) can verify that 332 - the Session ID matches the hash of the public key 333 - the private key, which was used to compute the digital signaling, 334 matches to the public key (by verifying the digital signature) 335 - the authorization indication is fresh (verifying the timestamp) 337 Note that this approach does not require a public key 338 infrastructure. It only makes use of the inability of an adversary 339 to later compute a key pair whereby the hash of public matches the 340 session identifier. Since the session identifier is stored at the 341 individual routers along the path it is not possible adversary to 342 masquerade the owner of the session id. 344 As described above replay protection is provided with the help of 345 timestamps. 347 The disadvantages of this approach are: 348 - Performance for the public key operation 349 - Size of the messages (the public key has to be included in 350 addition to other fields) 351 - Only the creator of the key pair is able to authorize actions (if 352 we ignore delegation approaches). This seems to be very restrictive. 354 [WC02] follows a similar approach by distributing a public key along 355 the path. Whenever an update is required then the message containing 356 the previous session identifier, the new session identifier, the 357 public key and a sequence number. The sequence number field is not 358 only a short random number; instead it is a digital signature 359 computed over the care-of address and the sequence number. A 360 successful verification at the cross-over router stores the new 361 values along the entire path. 363 3.2.2 Hash Series Based Approach 365 The Hash Series approach provides better performance than the PBK- 366 based approach. To set up the protocol a random T0 number is created 367 and hashed n times as shown below. The length of the hash series is 368 chosen by the creator with the value n: 370 T1=hash(T0) 371 T2=hash(T1) 372 ... 373 Tn=hash(Tn-1) 375 The session identifier is chosen in such a way that it equals Tn. 377 The hash values are then released in the reverse order. Every hash 378 value is used only once and the number of the latest hash value has 379 to be stored. Since the total number of hash values has to be set at 380 protocol startup it is necessary to "change" the hash series after 381 all values are exhausted. Since the hash series is associated to the 382 session identifier it is also necessary to change the session 383 identifier or to restart the protocol with a new session identifier. 385 A signaling message would therefore include: 386 - Session ID (=Tn) 387 - Total number of hash values (n) 388 - Current hash value (Ti) 389 - Index of current hash value (i) 391 A verifying entity would therefore recompute the hash chain to 392 verify that the session id is valid. Furthermore it is necessary to 393 compare the received hash value with the lasted one received (if no 394 hash value got lost) Tx+1 would have to equal hash(Tx). 396 To prevent reuse of a hash value by an adversary it is necessary 397 that all nodes along the path store the latest valid value. 399 3.2.3 Confidentiality protection of session identifier 401 This approach is very simple and follows the following arguments: 402 - An adversary can only mount an attack if it knows the Session ID 403 - The end host has to trust the intermediate nodes and networks to 404 perform according to the expected behavior. Due to the flexible 405 protocol operation it is necessary for intermediate nodes to act on 406 behalf of the end host. 408 Providing confidentiality protection to protect the Session ID makes 409 it more very difficult for an adversary to eavesdrop the session 410 identifier and to reuse it for a subsequent attack. 412 Confidentiality protection of the session identifier therefore 413 addresses attacks from outsiders (entities which do not actively 414 participate in the NSIS signaling protocol). Hence it must be 415 assured that the session identifier is never transmitted in clear 416 between two signaling entities (e.g. in clear over the wireless 417 link). Adversaries along the path (i.e. an NSIS node which was 418 intercepted by an adversary) are not addressed by this approach. 420 It is obvious that the session identifier must be chosen in a way 421 which does not allow an adversary to guess it. One possibility is to 422 choose the value for the Session Identifier randomly with each 423 session. It must be ensured that the identifier is sufficient large 424 (e.g. 128 bits). 426 This approach was selected for CASP [CASP]. 428 4. Pending Issues 430 - Replay protection 432 Replay protection for the solutions described in Section 3 is hard. 433 Assuming globally synchronized clocks for timestamp-based replay 434 protection is possibly hard to justify. 436 - Authorizing entity 438 To keep the NSIS protocol flexible it seems that it is undesirable 439 to restrict certain actions only to a single entity (e.g. to the 440 signaling initiator). Some solutions discussed in Section 3 tend to 441 force such an approach. The question therefore is: "Which entity is 442 allowed to authorize which actions?" 444 - Certain solutions discussed in Section 3 require the distribution 445 (and storage) of information along the path. 447 - Signaling message behavior 449 NSIS signaling messages do not always travel end-to-end. Instead, in 450 mobility scenarios it is sometimes desirable to start or to 451 terminate the signaling message exchange somewhere along the path. 452 Is this still valid or do all message have to travel end-to-end? 454 - Local or global solution 456 It is obviously much simpler to provide a solution which works 457 locally. Since the ownership problem could possibly require 458 verification at any node along the path it seems to be that a global 459 solution should be targeted. 461 5. Summary 463 To provide proper security for the session ownership problem a 464 solution has to face many challenges including performance, state 465 maintenance, replay protection and most important - the flexibility 466 of the NSIS protocol itself. 468 The above-described problem of authorization is not restricted to 469 communication at the edge as described above. The problem basically 470 occurs anywhere in the network whenever an old path becomes invalid 471 and a reservation along a new path has to be established. The merge 472 point (or cross-over router from the above mobility scenario) has to 473 make sure that only the legitimate owner of the reservation issued 474 this request. 476 Introducing a session identifier for the purpose of more efficient 477 mobility handling needs to be carefully compared to the additionally 478 introduced complexity (for example by the corresponding security 479 mechanism). The benefits gained by this new concept can easily be 480 destroyed by heavy-weight security mechanisms or by introducing new 481 security vulnerabilities. 483 6. Security Considerations 485 This document addresses security issues of the Session ID. To 486 provide a more detailed threat analysis it is necessary to resolve 487 the pending issues listed in Section 4. 489 This threat is also briefly described in [THREATS]. 491 The solutions described in this document to not aim to provide 492 protection for signaling messages itself. 494 7. Open Issues 496 Adding multicast handling to an NSIS adds a number of further open 497 issues. In case of multicast it is possible that nodes join and 498 leave the multicast group. If sensitive information is transmitted 499 to the active signaling entities then a previously joined node can 500 later perform some actions even after leaving the multicast group. 502 Sooner or later it is necessary to come up with a definition of the 503 problem we are aiming to solve. Such a definition might look like: 504 "An NSIS message is authentic if it originates from the initiator 505 for a session, or from an NSIS node that has been authorized to act 506 on behalf of the initiator by virtue of taking part in the NSIS 507 signaling session." 509 8. References 511 [THREATS] H. Tschofenig and D. Kroeselberg: "Security Threats for 512 NSIS", Internet Draft, Internet Engineering Task Force, March 2003. 513 Work in progress. 515 [NSIS-FW] R. Hancock, I. Freytsis, G. Karagiannis, J. Loughney and 516 S. Van den Bosch: "Next Steps in Signaling: Framework", Internet 517 Draft, Internet Engineering Task Force, March 2003. Work in 518 progress. 520 [PBK] S. Bradner, A. Mankin, and J. Schiller, "A framework for 521 purpose built keys (PBK)", Internet Draft, Internet Engineering Task 522 Force, November 2002. Work in progress. 524 [WC02] C. Westphal and H. Chaskar: "QoS Signaling Framework for 525 Mobile IP", Internet Draft, Internet Engineering Task Force, June 526 2002. Expired. 528 [CASP] H. Schulzrinne, H. Tschofenig, X. Fu, and A. McDonald, 529 "CASP - Cross-Application Signaling Protocol", Internet Draft, 530 Internet Engineering Task Force, 2003. Work in progress. 532 [RFC3521] L. Hamer, B. Gage, and H. Shieh, "Framework for session 533 set-up with media authorization," RFC 3521, Internet Engineering 534 Task Force, April 2003. 536 [RFC3520] L. Hamer, B. Gage, B. Kosinski, and H. Shieh, "Session 537 Authorization Policy Element", RFC 3520, Internet Engineering Task 538 Force, April 2003. 540 [Tho02] M. Thomas: "Analysis of Mobile IP and RSVP Interactions", 541 Internet Draft Internet Engineering Task Force, (work in progress), 542 October 2002. 544 Acknowledgments 546 We would like to thank Rainer Falk for his comments to this draft. 548 Author's Addresses 550 Hannes Tschofenig 551 Siemens AG 552 Otto-Hahn-Ring 6 553 81739 Munich 554 Germany 555 EMail: Hannes.Tschofenig@siemens.com 557 Henning Schulzrinne 558 Dept. of Computer Science 559 Columbia University 560 1214 Amsterdam Avenue 561 New York, NY 10027 562 USA 563 EMail: schulzrinne@cs.columbia.edu 565 Robert Hancock 566 Roke Manor Research 567 Old Salisbury Lane 568 Romsey 569 Hampshire 570 SO51 0ZN 571 United Kingdom 572 Email: robert.hancock@roke.co.uk 573 Andrew McDonald 574 Roke Manor Research 575 Old Salisbury Lane 576 Romsey, Hampshire 577 UK 578 EMail: andrew.mcdonald@roke.co.uk 580 Xiaoming Fu 581 Institute for Informatics 582 University of Goettingen 583 Lotzestrasse 16-18 584 37083 Goettinge 585 Germany EMail: fu@cs.uni-goettingen.de 587 Intellectual Property Statement 589 The IETF takes no position regarding the validity or scope of any 590 intellectual property or other rights that might be claimed to 591 pertain to the implementation or use of the technology described in 592 this document or the extent to which any license under such rights 593 might or might not be available; neither does it represent that it 594 has made any effort to identify any such rights. Information on the 595 IETF's procedures with respect to rights in standards-track and 596 standards-related documentation can be found in BCP-11. Copies of 597 claims of rights made available for publication and any assurances 598 of licenses to be made available, or the result of an attempt made 599 to obtain a general license or permission for the use of such 600 proprietary rights by implementors or users of this specification 601 can be obtained from the IETF Secretariat. 603 The IETF invites any interested party to bring to its attention any 604 copyrights, patents or patent applications, or other proprietary 605 rights which may cover technology that may be required to practice 606 this standard. Please address the information to the IETF Executive 607 Director. 609 Full Copyright Statement 611 Copyright (C) The Internet Society (2001). All Rights Reserved. 612 This document and translations of it may be copied and furnished to 613 others, and derivative works that comment on or otherwise explain it 614 or assist in its implementation may be prepared, copied, published 615 and distributed, in whole or in part, without restriction of any 616 kind, provided that the above copyright notice and this paragraph 617 are included on all such copies and derivative works. However, this 618 document itself may not be modified in any way, such as by removing 619 the copyright notice or references to the Internet Society or other 620 Internet organizations, except as needed for the purpose of 621 developing Internet standards in which case the procedures for 622 copyrights defined in the Internet Standards process must be 623 followed, or as required to translate it into languages other than 624 English. 626 The limited permissions granted above are perpetual and will not be 627 revoked by the Internet Society or its successors or assigns. 629 This document and the information contained herein is provided on an 630 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 631 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 632 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 633 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 634 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.