idnits 2.17.1 draft-mraihi-inch-thraud-09.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document is more than 15 pages and seems to lack a Table of Contents. == The page length should not exceed 58 lines per page, but there was 7 longer pages, the longest (page 2) being 119 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 26 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 2 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors 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 (December 22, 2009) is 5236 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Missing reference section? 'RFC5070' on line 1032 looks like a reference -- Missing reference section? 'UML' on line 1038 looks like a reference -- Missing reference section? 'RFC2119' on line 1024 looks like a reference -- Missing reference section? 'RFC4519' on line 1029 looks like a reference -- Missing reference section? 'ISO4217' on line 681 looks like a reference -- Missing reference section? 'RFC3023' on line 1027 looks like a reference Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft David M'Raihi 3 Category: Informational VeriSign 4 Document: draft-mraihi-inch-thraud-09.txt Sharon Boeyen 5 Expires: June 2010 Entrust 6 Michael Grandcolas 7 Grandcolas Consulting 8 LLC 9 Siddharth Bajaj 10 VeriSign 11 December 22, 2009 13 Sharing Transaction Fraud Data 15 Status of this Memo 17 This Internet-Draft is submitted to IETF in full conformance 18 with the provisions of BCP 78 and BCP 79. 20 Internet-Drafts are working documents of the Internet 21 Engineering Task Force (IETF), its areas, and its working 22 groups. Note that other groups may also distribute working 23 documents as Internet-Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six 26 months and may be updated, replaced, or obsoleted by other 27 documents at any time. It is inappropriate to use Internet- 28 Drafts as reference material or to cite them other than as "work 29 in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on June 22, 2010. 39 Copyright Notice 41 Copyright (c) 2009 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with 49 respect to this document. Code Components extracted from this 50 document must include Simplified BSD License text as described 51 in Section 4.e of the Trust Legal Provisions and are provided 52 without warranty as described in the BSD License. 54 Sharing Transaction Fraud Data December 2009 56 Abstract 58 This document describes a document format for exchanging 59 transaction fraud (Thraud) information. It extends the Incident 60 Handling Working Group (INCH WG) Incident Object Description 61 Exchange Format (IODEF) incident reporting document format. 63 Sharing Transaction Fraud Data December 2009 65 Table of Contents 67 1. Introduction 4 68 2. Requirements Terminology 5 69 3. Anatomy of a Transaction Fraud 5 70 4. IODEF-Document Incident Class 7 71 5. Thraud Record Class Definitions 8 72 5.1. FraudEventPaymentType Class 9 73 5.1.1. PayeeName 10 74 5.1.2. PostalAddress 10 75 5.1.3. PayeeAmount 10 76 5.2. FraudEventTransferType Class 10 77 5.2.1. BankID 11 78 5.2.2. AccountID 12 79 5.2.3. AccountType 12 80 5.2.4. TransferAmount 13 81 5.3. FraudEventIdentityType Class 13 82 5.3.1. IdentityComponent 13 83 5.4. FraudEventOtherType Class 14 84 5.4.1. OtherEventType 14 85 5.4.2. OtherEventDescription 15 86 5.5. AmountType Class 15 87 5.5.1. Class Contents 15 88 5.5.2. Currency 15 89 5.6. AccountTypeType Class 15 90 6. IODEF Profile for an Activity Thraud Report 16 91 6.1. Mandatory components 16 92 6.2. Recommended Components 16 93 6.3. Deprecated Components 17 94 7. IODEF profile for a Signature Thraud Report 18 95 8. IODEF Additional Attribute Values 19 96 8.1. Purpose Attribute 19 97 9. Security considerations 19 98 10. IANA considerations 20 99 10.1. Media sub-type 20 100 10.2. XML namespace 21 101 11. Conclusion 21 102 12. References 22 103 12.1. Normative 22 104 12.2. Informative 22 105 13. Authors' Addresses 22 106 Appendix A. Thraud Record XML Schema 24 107 Appendix B. Example of a Thraud Report 25 109 Sharing Transaction Fraud Data December 2009 111 1. Introduction 113 Financial organizations and merchants that offer online access 114 to their services frequently encounter fraud perpetrated against 115 their customers' accounts. In their attempts to combat these 116 frauds, the organizations and their law enforcement agencies 117 could benefit greatly by sharing intelligence about fraud 118 incidents and patterns with similar organizations and agencies. 119 This specification standardizes a document format by which they 120 can share such information. It is intended to facilitate multi- 121 vendor interoperability between conformant components of an open 122 fraud reporting framework. 124 Information sharing can take place directly between financial 125 organizations and merchants. However, the power of shared 126 intelligence is multiplied many times if the information is 127 gathered from multiple sources by a shared network, consolidated 128 and redistributed to participants. 130 In this arrangement, incident reports submitted to the network 131 are called inbound reports, and reports issued by the network 132 are called outbound reports. 134 Inbound reports will be submitted using a push-style protocol 135 (such as email or SOAP). And outbound reports will either be 136 distributed using a push-style protocol or a request/response 137 protocol (such as HTTP). 139 Inbound reports identify the contributor of the report, as this 140 information is essential in evaluating the quality of the 141 information it contains and in contacting the source for the 142 purpose of clarification. But, outbound reports commonly do not 143 identify the original sources, as those sources may not wish to 144 be identified to other subscribers. Such reports should, 145 instead, identify the consolidator as the source. 147 A report may describe a particular transaction that is known to 148 be, or believed to be, fraudulent, or it may describe a pattern 149 of behavior that is believed to be indicative of fraud. The 150 former type of report is called an 'activity report' and the 151 latter a 'signature report'. 153 The schema defined herein extends the IODEF XML incident 154 reporting schema [RFC5070]. 156 In section 3 we introduce the actors in a typical transaction 157 fraud. Fraud reporting by means of an IODEF-Document is 158 described in section 4. We define the elements of a Thraud 159 Report in section 5. In section 6 we describe the Activity 160 Thraud Report profile of the IODEF specification. And in section 161 7 the profile for a Signature Thraud Report is described. In 162 section 8 we define new attribute values for the IODEF Incident 164 Sharing Transaction Fraud Data December 2009 166 class. Security considerations are described in section 9. And, 167 section 10 contains a request to IANA to register the associated 168 media sub-type and XML namespace identifier. The Appendices 169 contain the complete XML schema and a sample Thraud Report. 171 Data elements in this document are expressed in Unified Modeling 172 Language (UML) syntax [UML]. 174 XML namespace prefixes are used throughout this document to 175 stand for their respective XML namespaces, as follows. 177 iodef: urn:ietf:params:xml:ns:iodef-1.0 178 thraud: urn:ietf:params:xml:ns:thraud-1.0 179 xs: http://www.w3.org/2001/XMLSchema 180 xsi: http://www.w3.org/2001/XMLSchema-instance 182 2. Requirements Terminology 184 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 185 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 186 "OPTIONAL" in this document are to be interpreted as described 187 in RFC 2119 [RFC2119]. 189 3. Anatomy of a Transaction Fraud 191 The actors in a typical transaction fraud are shown in Figure 1. 193 Sharing Transaction Fraud Data December 2009 195 +--------------------------------------+ 196 | Fraudsters | 197 | (collect & verify victim credentials | 198 | via phishing, malware, etc.) | 199 +--------------------------------------+ 200 | 201 |recruit 202 | 203 | ----------------disburse profits----------------- 204 | | | 205 v v | 206 +-----------+ +--------------+ +-------+ 207 | | | | | Fraud | 208 | |--Open Dest Acct-->| Financial |---->| Dest. | 209 | | | Organization | |Account| 210 | Fraud | +--------------+ +-------+ 211 | Executors | ^ funds 212 | | | transfer 213 | | +--------------+ +-------+ 214 | | | Victim's | | | 215 | |---Init Transfer-->| Financial |<-o--|Victim | 216 | | | Organization | | |Account| 217 +-----------+ +--------------+ | +-------+ 218 v 219 +-----------+ 220 | Fraud | 221 | Detection | 222 | Sensors | 223 |(realtime/ | 224 | offline) | 225 +-----------+ 227 Figure 1. Transaction Fraud Elements 229 Transaction fraud activities normally involve the following 230 actors: 232 1. Fraudsters are individuals or organizations that collect 233 victims' login credentials using a variety of means, including 234 phishing and malware, and verify them (usually by attempting to 235 login to the victim's account). Then the Fraudsters may either 236 recruit Fraud Executors themselves or wholesale the victims' 237 credentials to other Fraudsters, who will, in turn, recruit 238 Fraud Executors. 240 2. Fraud Executors are individuals who attempt the 241 fraudulent funds transfer or payment. In the case of fraudulent 242 funds transfers, an account at the same financial organization 243 as that of the victim, or a different one, is opened, as the 244 destination account for the fraudulent transfer. Alternatively, 245 a fraudulent payment is made using a check or electronic 246 transfer. 248 Sharing Transaction Fraud Data December 2009 250 3. Victims of both credential theft and transaction fraud. 252 4. Financial Organizations that hold the victim's and the 253 Fraud Executor's accounts. 255 5. Sensors at the Financial Organization that detect 256 fraudulent transaction attempts, either in real-time or after 257 the fact. 259 The intention of Thraud reporting is to enable any organization 260 that has detected fraud to share this information, either 261 internally or with other potential victim organizations. The 262 receiving organization can use this information, for example, to 263 institute manual review of transactions initiated from 264 suspicious IP addresses. 266 4. IODEF-Document Incident Class 268 A Thraud Report SHALL be an instance of the IODEF-Document 269 class, as defined in [RFC5070]. The report SHALL contain at 270 least one Incident object, as defined in [RFC5070]. Each 271 Incident object SHOULD contain information about a single fraud 272 strategy. One Incident object MAY contain information about 273 multiple fraudulent transactions that are consistent with the 274 same fraud strategy. Each fraudulent transaction SHALL be 275 described in a separate EventData object. The data model for the 276 Incident class is defined in [RFC5070] and is repeated here, as 277 Figure 2, for the reader's convenience. 279 Sharing Transaction Fraud Data December 2009 281 +-------------+ 282 | Incident | 283 +-------------+ 284 |ENUM |<>----------[ IncidentID ] 285 | purpose |<>--{0..1}--[ AlternativeID ] 286 |STRING |<>--{0..1}--[ RelatedActivity ] 287 | ext-purpose |<>--{0..1}--[ DetectTime ] 288 |ENUM |<>--{0..1}--[ StartTime ] 289 | lang |<>--{0..1}--[ EndTime ] 290 |ENUM |<>----------[ ReportTime ] 291 | restriction |<>--{0..*}--[ Description ] 292 | |<>--{1..*}--[ Assessment ] 293 | |<>--{0..*}--[ Method ] 294 | |<>--{1..*}--[ Contact ] 295 | |<>--{1..*}--[ EventData ]<>--[ AdditionalData ] 296 | |<>--{0..1}--[ History ] 297 | |<>--{1..*}--[ AdditionalData ] 298 +-------------+ 300 Figure 2. Data model of the Incident class 302 The AdditionalData abstract class is an extension point in the 303 schema of the EventData class. Implementers SHALL include 304 exactly one of the following objects in AddtionalData: 305 FraudEventPayment, FraudEventTransfer, FraudEventIdentity and 306 FraudEventOther. Collectively, these are known as Thraud 307 Records. The corresponding classes are defined by this 308 specification in section 5, below. 310 The Thraud profile of the Incident class is defined in sections 311 6 and 7, below. 313 5. Thraud Record Class Definitions 315 Thraud Records are expressed in XML. Therefore, the dtype 316 attribute of the AdditionalData element SHALL be assigned the 317 value 'xml'. 319 A payment Thraud Record SHALL be structured as shown in Figure 320 3. See also section 5.1. 322 +------------------+ 323 | AdditionalData | 324 +------------------+ 325 | ENUM dtype (xml) |<>-----[ FraudEventPayment ] 326 +------------------+ 328 Figure 3. The FraudEventPayment extension 330 A funds-transfer Thraud Record SHALL be structured as shown in 331 Figure 4. See also section 5.2. 333 Sharing Transaction Fraud Data December 2009 335 +------------------+ 336 | AdditionalData | 337 +------------------+ 338 | ENUM dtype (xml) |<>-----[ FraudEventTransfer ] 339 +------------------+ 341 Figure 4. The FraudEventTransfer extension 343 An identity Thraud Record SHALL be structured as shown in Figure 344 5. See also section 5.3. 346 +------------------+ 347 | AdditionalData | 348 +------------------+ 349 | ENUM dtype (xml) |<>-----[ FraudEventIdentity ] 350 +------------------+ 352 Figure 5. The FraudEventIdentity extension 354 Other Thraud Records SHALL be structured as shown in Figure 6. 355 See also section 5.4. The FraudEventOther class has an open 356 definition to act as a placeholder for event types that emerge 357 in the future. 359 +------------------+ 360 | AdditionalData | 361 +------------------+ 362 | ENUM dtype (xml) |<>----[ FraudEventOther ] 363 +------------------+ 365 Figure 6. The FraudEventOther extension 367 5.1. FraudEventPaymentType Class 369 The FraudEventPaymentType class is used to report payee 370 instructions for a fraudulent payment or fraudulent payment 371 attempt. Fraudsters sometimes use the same payee instructions 372 (including the amount) for multiple fraudulent payment attempts. 373 By reporting the payment instructions used in the fraud, other 374 oragnizations may be able to detect similar fraudulent payment 375 attempts to the same payee. 377 The structure of the FraudEventPaymentType class SHALL be as 378 shown in Figure 7. 380 Sharing Transaction Fraud Data December 2009 382 +-------------+ 383 | FraudEvent- | 384 | PaymentType | 385 +-------------+ 386 | |<>--{0..1}--[ PayeeName ] 387 | |<>--{0..1}--[ PostalAddress ] 388 | |<>--{0..1}--[ PayeeAmount ] 389 +-------------+ 391 Figure 7. The FraudEventPaymentType class 393 The contents of the FraudEventPaymentType class are described 394 below. At least one component MUST be present. 396 5.1.1. PayeeName 398 Zero or one value of type iodef:MLString. The name of the payee. 400 5.1.2. PostalAddress 402 Zero or one value of type iodef:MLString. The format SHALL be as 403 documented in Sections 2.23 of [RFC4519], which defines a postal 404 address as a free-form multi-line string separated by the "$" 405 character. 407 5.1.3. PayeeAmount 409 Zero or one value of type thraud:AmountType. See Section 5.5. 411 5.2. FraudEventTransferType Class 413 The FraudEventTransferType class is used to report the payee 414 instructions for a fraudulent funds transfer or fraudulent funds 415 transfer attempt. Fraudsters sometimes use the same payee 416 instructions (including the amount) for multiple fraudulent 417 funds transfer attempts. By reporting the funds transfer 418 instructions used in the fraud, other organizations may be able 419 to detect similar fraudulent funds transfer attempts to the same 420 payee. 422 The structure of the FraudEventTransferType class SHALL be as 423 shown in Figure 8. 425 Sharing Transaction Fraud Data December 2009 427 +--------------+ 428 | FraudEvent- | 429 | TransferType | 430 +--------------+ 431 | |<>--{0..1}--[ BankID ] 432 | |<>--{0..1}--[ AccountID ] 433 | |<>--{0..1}--[ AccountType ] 434 | |<>--{0..1}--[ TransferAmount ] 435 +--------------+ 437 Figure 8. The FraudEventTransferType class 439 The contents of the FraudEventTransferType class are described 440 below. At least one component MUST be present. 442 5.2.1. BankID 444 Zero or one value of type thraud:BankIDType. The structure of 445 the BankIDType class SHALL be as shown in Figure 9. The contents 446 SHALL be of type xs:string. The namespace attribute SHALL be of 447 type xs:anyURI and SHALL identify the numbering system used to 448 identify the bank or account. 450 +-------------------+ 451 | BankIDType | 452 +-------------------+ 453 | STRING | 454 | | 455 | STRING namespace | 456 +-------------------+ 458 Figure 9. The BankIDType class 460 A list of registered namespace identifiers is maintained at: 462 http://www.openauthentication.org/thraud/resources/bank-id- 463 namespace.htm 465 The following namespace attribute values and their semantics are 466 registered. 468 http://www.openauthentication.org/thraud/resources/bank-id- 469 namespace.htm#american_bankers_association 471 One of the nine-digit Routing Numbers registered to the 472 financial organization that holds the account, as administered 473 by The American Bankers Association. 475 http://www.openauthentication.org/thraud/resources/bank-id- 476 namespace.htm#canadian_payments_association 478 Sharing Transaction Fraud Data December 2009 480 The three digit Institution Number registered to the financial 481 organization that holds the account, as administered by The 482 Canadian Payments Association. 484 http://www.openauthentication.org/thraud/resources/bank-id- 485 namespace.htm#iso13616_1_2007 487 The corresponding AccountId represents the ISO 13616 488 International Bank Account Number [ISO13616-1:2007] in the 489 'electronic form' (i.e. containing no spaces) that is assigned 490 to the account, as administered by the Society for Worldwide 491 Interbank Financial Telecommunication (SWIFT). The 492 corresponding BankId xs:string value SHOULD be set to the null 493 string. Receiving organizations SHOULD ignore the corresponding 494 BankId value. 496 http://www.openauthentication.org/thraud/resources/bank-id- 497 namespace.htm#iso9362_1994 499 The eight character Bank Identifier Code [ISO9362:1994] 500 registered to the financial organization that holds the account, 501 as administered by SWIFT. 503 Other namespace values MUST be agreed between participants. 504 Requests to register new values SHOULD be made at: 506 http://www.openauthentication.org/thraud/form/bank-id- 507 namespace 509 Note that a single organization may be identified by more than 510 one value for any one or more of these namespaces. So, receiving 511 organizations SHOULD take this into account in their matching 512 procedure. 514 5.2.2. AccountID 516 Zero or one value of type xs:string. The destination primary 517 account number, as administered by the financial organization 518 identified in the BankId element. In the case where the BankId 519 namespace attribute value is 'iso13616_1_2007', this element 520 SHALL contain the International Bank Account Number in the 521 'electronic form' (i.e. containing no spaces) that is assigned 522 to the account. In all other cases, the element SHALL contain 523 only the account number, as administered by the financial 524 organization that holds the account. The reporting organization 525 SHALL remove all prefixes that identify the country, bank or 526 branch. 528 5.2.3. AccountType 530 Zero or one value of type thraud:AccountTypeType. See section 531 5.6. 533 Sharing Transaction Fraud Data December 2009 535 5.2.4. TransferAmount 537 Zero or one value of type thraud:AmountType. See Section 5.5. 539 5.3. FraudEventIdentityType Class 541 The FraudEventIdentityType class is used to report a fraudulent 542 impersonation or fraudulent impersonation attempt. By reporting 543 the impersonation event, other potential victims may be able to 544 detect similar fraudulent impersonation attempts. 546 The structure of the FraudEventIdentityType class SHALL be as 547 shown in Figure 10. 549 +--------------+ 550 | FraudEvent- | 551 | IdentityType | 552 +--------------+ 553 | |<>--{1..*}--[ IdentityComponent ] 554 +--------------+ 556 Figure 10. The FraudEventIdentityType class 558 The contents of the FraudEventIdentityType class are described 559 below. 561 5.3.1. IdentityComponent 563 One or more values of type iodef:ExtensionType. This 564 specification defines two extensions: EmailAddress and UserID. 566 5.3.1.1. EmailAddress 568 In reporting an identity fraud event, the reporting institution 569 MAY include the victim's email address. This SHALL be achieved 570 by placing an object of type iodef:Email in the 571 IdentityComponent object. It SHALL contain the email address of 572 the intended fraud victim. 574 The IdentityComponent.dtype attribute SHALL be set to the value 575 "string". 577 The IdentityComponent.meaning attribute SHALL be set to the 578 value "victim email address". 580 5.3.1.2. UserID 582 In reporting an identity fraud event, the reporting institution 583 MAY include the victim's user id. This SHALL be achieved by 584 placing an object of type iodef:ExtensionType in the 585 IdentityComponent object. The data type of the extension 587 Sharing Transaction Fraud Data December 2009 589 contents SHALL be xs:string. It SHALL contain the user id of the 590 intended fraud victim. 592 The IdentityComponent.type attribute SHALL be set to the value 593 "string". 595 The IdentityComponent.meaning attribute SHALL be set to the 596 value "victim user id". 598 5.4. FraudEventOtherType Class 600 The FraudEventOtherType class SHALL be used to report fraudulent 601 events other than those detailed above, such as new event types 602 that may emerge at some time in the future. This class enables 603 such events to be reported, using this specification, even 604 though the specific characteristics of such events have not yet 605 been formally identified. By reporting the details of these 606 unspecified event types, other institutions may be able to 607 detect similar fraudulent activity. 609 The structure of the FraudEventOtherType class SHALL be as shown 610 in Figure 11. 612 +-------------+ 613 | FraudEvent- | 614 | OtherType | 615 +-------------+ 616 | |<>----------[ OtherEventType ] 617 | |<>--{0..1}--[ PayeeName ] 618 | |<>--{0..1}--[ PostalAddress ] 619 | |<>--{0..1}--[ BankID ] 620 | |<>--{0..1}--[ AccountID ] 621 | |<>--{0..1}--[ AccountType ] 622 | |<>--{0..1}--[ PayeeAmount ] 623 | |<>--{0..1}--[ OtherEventDescription ] 624 +-------------+ 626 Figure 11. The FraudEventOtherType class 628 Many of the components of the FraudEventOtherType class are also 629 components of the FraudEventPaymentType or 630 FraudEventTransferType classes. Their use in the 631 FraudEventOtherType class is identical to their use in those 632 classes. Therefore, their descriptions are not duplicated here. 633 Only components that are unique to the FraudEventOtherType class 634 are described below. 636 5.4.1. OtherEventType 638 One value of type xs:anyURI. A name that classifies the event. 640 Sharing Transaction Fraud Data December 2009 642 A list of registered other event type identifiers is maintained 643 at: 645 http://www.openauthentication.org/thraud/resources/other- 646 event-type 648 Requests to register new values SHOULD be made at: 650 http://www.openauthentication.org/thraud/form/other-event- 651 type 653 5.4.2. OtherEventDescription 655 Zero or one value of type iodef:MLString. A free-form textual 656 description of the event. 658 5.5. AmountType Class 660 The AmountType class SHALL be as shown in Figure 12. It SHALL be 661 used to report the amount of a payment or transfer fraud. 663 +------------------+ 664 | AmountType | 665 +------------------+ 666 | DECIMAL | 667 | | 668 | STRING currency | 669 +------------------+ 671 Figure 12. The AmountType Class 673 The contents of the AmountType class are described below. 675 5.5.1. Class Contents 677 REQUIRED DECIMAL. The amount of the payment or transfer. 679 5.5.2. Currency 681 REQUIRED STRING. The three letter currency code [ISO4217]. 683 5.6. AccountTypeType Class 685 The AccountTypeType class SHALL be as shown in Figure 13. It 686 SHALL be used to report the type of the destination account. 688 Sharing Transaction Fraud Data December 2009 690 +-----------------+ 691 | AccountTypeType | 692 +-----------------+ 693 | STRING | 694 | | 695 | STRING lang | 696 +-----------------+ 698 Figure 13. The AccountTypeType class 700 Receiving organizations MUST be capable of processing contents 701 containing spelling variations. 703 6. IODEF Profile for an Activity Thraud Report 705 This section describes the profile of the IODEF Incident class 706 for a compliant Activity Thraud Report. 708 6.1. Mandatory components 710 A Thraud Report SHALL conform to the data model specified for an 711 IODEF-Document in [RFC5070]. The following components of that 712 data model, while optional in IODEF, are REQUIRED in a 713 conformant Thraud Report. 715 Receiving organizations MAY reject documents that do not contain 716 all these components. Therefore, reporting organizations MUST 717 populate them all. 719 Except where noted, these components SHALL be interpreted as 720 described in [RFC5070]. 722 Incident.Contact.ContactName - The name of the reporting 723 organization. In case the reporting organization acts as a 724 consolidator of reports from other organizations, elements of 725 this class SHALL contain the name of the consolidator. 726 Incident.Contact.Email - An email address at which the reporting 727 organization may be contacted. 728 Incident.Contact.Telephone 729 Incident.EventData 730 Incident.EventData.AdditionalData - SHALL contain exactly one 731 Thraud Record. 733 6.2. Recommended Components 735 Receiving organizations SHOULD be capable of processing the 736 following components. However, they MUST NOT reject documents 737 either because they are present or absent. 739 Sharing Transaction Fraud Data December 2009 741 If available, reporting organizations SHOULD include these 742 components in Thraud Reports. Except where noted, these 743 components SHALL be interpreted as described in [RFC5070]. 745 Incident.Contact.Contact 746 Incident.Contact.Contact.ContactName - The name of the reporting 747 fraud analyst. 748 Incident.Contact.Contact.Email - The email address of the 749 reporting fraud analyst. 750 Incident.Contact.Contact.Telephone - The telephone number of the 751 reporting fraud analyst. 752 Incident.EventData.Method 753 Incident.EventData.Method.Description 754 Incident.Assessment.Confidence 755 Incident.Assessment.Impact 756 Incident.Assessment.MonetaryImpact 757 Incident.EventData.DetectTime 758 Incident.EventData.StartTime 759 Incident.EventData.EndTime 760 Incident.EventData.Flow 761 Incident.EventData.Flow.System 762 Incident.EventData.Flow.System.Service 763 Incident.EventData.Flow.System.Node.NodeName 764 Incident.EventData.Flow.System.Node.Address 766 6.3. Deprecated Components 768 This profile provides no guidance to receiving organizations on 769 the proper processing of the following components. Therefore, 770 the reporting organization has no assurance that the receiving 771 organization will handle them in an appropriate manner and 772 SHOULD NOT include them in a Thraud Report. However, receiving 773 organizations MUST NOT reject reports that do contain these 774 components. 776 Incident.DetectTime 777 Incident.AlternativeID 778 Incident.RelatedActivity 779 Incident.StartTime 780 Incident.EndTime 781 Incident.ReportTime 782 Incident.Description 783 Incident.Method 784 Incident.History 785 Incident.AdditionalData 786 Incident.ext-purpose 787 Incident.IncidentID.instance 788 Incident.Contact.Description 789 Incident.Contact.RegistyHandle 790 Incident.Contact.PostalAddress 791 Incident.Contact.Fax 792 Incident.Contact.TimeZone 794 Sharing Transaction Fraud Data December 2009 796 Incident.Contact.AdditionalData 797 Incident.Contact.Contact.Description 798 Incident.Contact.Contact.RegistyHandle 799 Incident.Contact.Contact.PostalAddress 800 Incident.Contact.Contact.Fax 801 Incident.Contact.Contact.TimeZone 802 Incident.Contact.Contact.AdditionalData 803 Incident.Contact.ext-role 804 Incident.Contact.ext-type 805 Incident.Contact.Contact.ext-role 806 Incident.Contact.Contact.ext-type 807 Incident.EventData.Method.Reference 808 Incident.EventData.Method.Reference.Description 809 Incident.EventData.Method.AdditionalData 810 Incident.EventData.Method.Reference.URL 811 Incident.Assessment.TimeImpact 812 Incident.Assessment.AdditionalData 813 Incident.Assessment.Impact.type 814 Incident.EventData.Description 815 Incident.EventData.Contact 816 Incident.EventData.Assessment 817 Incident.EventData.Expectation 818 Incident.EventData.Record 819 Incident.EventData.EventData 820 Incident.EventData.Flow.System.OperatingSystem 821 Incident.EventData.Flow.System.Counter 822 Incident.EventData.Flow.System.Description 823 Incident.EventData.Flow.System.AdditionalData 824 Incident.EventData.Flow.System.ext-category 825 Incident.EventData.Flow.System.Node.Location 826 Incident.EventData.Flow.System.Node.DateTime 827 Incident.EventData.Flow.System.Node.NodeRole 828 Incident.EventData.Flow.System.Node.Counter 829 Incident.EventData.Flow.System.Node.Address.ext-category 830 Incident.EventData.Flow.System.Service.ProtoType 831 Incident.EventData.Flow.System.Service.ProtoCode 832 Incident.EventData.Flow.System.Service.ProtoField 833 Incident.EventData.Flow.System.Service.Application 835 7. IODEF profile for a Signature Thraud Report 837 A Signature Thraud Report SHALL convey information about the 838 behavior associated with fraudulent events, rather than 839 reporting the details of the specific events themselves. 841 Sharing Signature Thraud Reports helps receiving organizations 842 to detect suspicious behavior in their own systems. 844 A Signature Thraud Report SHALL conform to the profile described 845 in section 6. 847 Sharing Transaction Fraud Data December 2009 849 8. IODEF Additional Attribute Values 851 Additional IODEF attribute standard values are defined here. 853 8.1. Purpose Attribute 855 The following additional values are defined for the 856 Incident.purpose attribute. 858 Add - The enclosed Thraud Record values SHOULD be added to the 859 corpus by the receiving organization. 861 Delete - The enclosed Thraud Record types SHOULD be deleted from 862 the corpus by the receiving organization. 864 Modify - The enclosed Thraud Record values SHOULD replace the 865 corresponding values in the corpus. Where no corresponding types 866 currently exist in the corpus, the enclosed values SHOULD be 867 added to the corpus by the receiving organization. 869 9. Security considerations 871 This document describes a document format for exchanging 872 information about successful or attempted transaction and 873 authentication fraud incidents. The information is intended to 874 be used to improve the effectiveness of participants' fraud 875 detection and prevention programs. The effectiveness of such 876 programs depends critically on the accuracy, reliability, 877 confidentiality and timeliness of both the information and the 878 participants in its exchange. Threats to accuracy, reliability 879 and confidentiality include (but are not limited to) those 880 described here. 882 Fraudsters may attempt to introduce reports that delete or 883 modify incident information in the corpus. Therefore, origin 884 authentication MUST be employed. Human review SHOULD be 885 performed prior to implementing modifications to the corpus. 887 Fraudsters may attempt to interrupt or redirect submissions, 888 thereby preventing the sharing of intelligence concerning their 889 fraud strategies. Therefore, authenticated receipts SHOULD be 890 employed. 892 Fraudsters may attempt to impersonate legitimate submitters, 893 thereby poisoning their reputations, and rendering ineffective 894 their future submissions. Origin authentication MUST be used to 895 ensure that the sources of reports are properly identified. 897 Fraudsters that can view incident reports may adapt their fraud 898 strategies to avoid detection. Therefore, reports MUST be 899 protected by confidentiality services including transport 900 encryption and access control. 902 Sharing Transaction Fraud Data December 2009 904 In order to prevent inadvertent disclosure of incident data, 905 incident reports SHOULD be encrypted while in storage. 907 The submitter of an incident report may incorrectly identify 908 legitimate activity as a fraud incident. This may lead to 909 denial of service by a receiving organization that relies on the 910 report or information derived from the report. Receiving 911 organizations SHOULD operate a reputation service, in which the 912 reliability of the information from particular sources is 913 assessed and tracked and subsequent reports are weighted 914 accordingly. The source of reports MUST be authenticated. 915 Receiving organizations SHOULD use reports to step-up 916 authentication assurance, rather than simply denying service. 918 A receiving organization may misuse a Thraud report to deny 919 service, resulting in a loss for a legitimate user. If such a 920 user were to learn the identity of the source of the information 921 that led to the denial of service, then that source may become 922 implicated in any resulting claim for compensation. This, in 923 turn, may discourage reporting organizations from participating 924 in intelligence sharing. Therefore, original sources SHOULD NOT 925 be identified in consolidated reports. 927 Any origin authentication and data integrity mechanism that is 928 acceptable to both parties MAY be used. 930 Any transport confidentiality mechanism that is acceptable to 931 both parties MAY be used. 933 This specification does not include a data compression 934 technique. Therefore, it does not introduce any denial of 935 service vulnerabilities related to decompression. 937 10. IANA considerations 939 This specification proposes the registration of two identifiers: 941 - The media sub-type name 'thraud+xml' in the standard 942 registration tree. 944 - The xml namespace identifier - urn:ietf:params:xml:ns:thraud- 945 1.0. 947 10.1. Media sub-type 949 Type name: application 951 Subtype name: thraud+xml 953 Required parameters: none. 955 Sharing Transaction Fraud Data December 2009 957 Optional parameters: same as the charset parameter of 958 application/xml as specified in [RFC3023]. 960 Encoding considerations: same as encoding considerations of 961 application/xml as specified in [RFC3023]. 963 Security considerations: this registration has all of the 964 security considerations described in [RFC3023] in addition to 965 those in section 9, above. 967 Interoperability considerations: this registration has all of 968 the interoperability considerations described in [RFC3023]. 970 Published specification: the media type data format is defined 971 in this specification. 973 Applications that use this media type: transaction and 974 authentication fraud analysis and reporting applications and 975 risk-based transaction and authentication evaluation 976 applications. 978 Additional information 979 Magic number(s): none 980 File extension: .tfi 981 Macintosh file type codes: none 983 Person and email address to contact for further information: D 984 M'Raihi, dmraihi@verisign.com 986 Intended usage - LIMITED USAGE 988 Restrictions on usage: thraud media are intended for no usage 989 other than the exchange of fraud intelligence data. 991 Author: D M'Raihi 993 Change controller: D M'Raihi 995 10.2. XML namespace 997 IANA is requested to register the xml namespace identifier: 998 urn:ietf:params:xml:ns:thraud-1.0. 1000 11. Conclusion 1002 This specification introduces a transaction fraud (Thraud) 1003 reporting document structure that enables the sharing of fraud 1004 data. Based on the IODEF-Document format, the proposed extension 1005 facilitates interoperability to increase the security of online 1006 applications. 1008 Sharing Transaction Fraud Data December 2009 1010 12. References 1012 12.1. Normative 1014 [ISO13616-1:2007] Financial services - International bank 1015 account number (IBAN) - Part 1: Structure of the IBAN, ISO 1016 13616-1:2007. 1018 [ISO4217:2008] Financial services - Codes for the 1019 representation of currencies and funds, ISO 4217:2008. 1021 [ISO9362:1994] Banking - Banking telecommunication messages 1022 - Bank identifier codes, ISO 9362:1994. 1024 [RFC2119] S. Bradner, "Key words for use in RFCs to 1025 Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 1027 [RFC3023] M. Murata, "XML Media Types", RFC 3023, Jan 2001. 1029 [RFC4519] A. Sciberras, "Schema for User Applications", RFC 1030 4519, June 2006. 1032 [RFC5070] R. Danyliw, The Incident Object Description 1033 Exchange Format, RFC 5070, December 2007, available at: 1034 http://www.rfc-editor.org/rfc/rfc5070.txt 1036 12.2. Informative 1038 [UML] Information technology - Open Distributed 1039 Processing - Unified Modeling Language (UML) Version 1.4.2, 1040 ISO/IEC 19501:2005. 1042 13. Authors' Addresses 1044 Primary point of contact (for sending comments and 1045 questions): 1047 David M'Raihi 1048 VeriSign, Inc. 1049 685 E. Middlefield Road 1050 Mountain View Phone: 1-650-426-3832 1051 CA 94043 USA Email: dmraihi@verisign.com 1053 Other Authors' contact information: 1055 Sharon Boeyen 1056 Entrust Inc. 1057 1000 Innovation Drive Phone: 1-613-270-3181 1058 Ottawa, ON, K2K 3E7 Email: sharon.boeyen@entrust.com 1060 Michael Grandcolas 1061 Grandcolas Consulting LLC. 1063 Sharing Transaction Fraud Data December 2009 1065 247 Ocean Park Blvd. Phone: 1-310-399-1747 1066 Santa Monica, Ca 90405 Email: michael.grandcolas@hotmail.com 1068 Siddharth Bajaj 1069 VeriSign, Inc. 1070 487 E. Middlefield Road 1071 Mountain View Phone: 1-650-426-3458 1072 CA 94043 USA Email: sbajaj@verisign.com 1074 Sharing Transaction Fraud Data December 2009 1076 Appendix A. Thraud Record XML Schema 1078 1079 1085 1088 1090 1092 1094 1096 1097 1098 1100 1102 1104 1105 1106 1107 1108 1110 1111 1113 1115 1116 1117 1118 1119 1121 1122 1123 1124 1125 1127 Sharing Transaction Fraud Data December 2009 1129 1131 1133 1135 1136 1138 1140 1142 1143 1144 1145 1146 1147 1148 1149 1150 1151 1152 1153 1154 1156 1157 1158 1159 1160 1162 Appendix B. Example of a Thraud Report 1164 1165 1169 1170 908711 1171 1172 2006-10-12T00:00:00-07:00 1173 1174 1175 1176 1177 1178 Example Corp. 1179 contact@example.com 1180 +1.972.555.0150 1182 Sharing Transaction Fraud Data December 2009 1184 1185 1186 2006-10-12T07:42:21-08:00 1187 1188 1189 1190
192.0.2.53
1191 1192 Source of numerous attacks 1193 1194 1195 1196 1201 123456789 1205 3456789 1206 saving 1207 10000 1208 1209 1210 1211 1212