doc: Add RFC documents

1 files changed, 2859 insertions, 0 deletions

diff --git a/doc/rfc/rfc5901.txt b/doc/rfc/rfc5901.txt
new file mode 100644
index 0000000..f62e6e6
--- /dev/null
+++ b/doc/rfc/rfc5901.txt
@@ -0,0 +1,2859 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                           P. Cain
+Request for Comments: 5901                   The Cooper-Cain Group, Inc.
+Category: Standards Track                                      D. Jevans
+ISSN: 2070-1721                          The Anti-Phishing Working Group
+                                                               July 2010
+
+
+     Extensions to the IODEF-Document Class for Reporting Phishing
+
+Abstract
+
+   This document extends the Incident Object Description Exchange Format
+   (IODEF) defined in RFC 5070 to support the reporting of phishing
+   events, which is a particular type of fraud.  These extensions are
+   flexible enough to support information gleaned from activities
+   throughout the entire electronic fraud cycle -- from receipt of the
+   phishing lure to the disablement of the collection site.  Both simple
+   reporting and complete forensic reporting are possible, as is
+   consolidating multiple incidents.
+
+Status of This Memo
+
+   This is an Internet Standards Track document.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Further information on
+   Internet Standards is available in Section 2 of RFC 5741.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc5901.
+
+Copyright Notice
+
+   Copyright (c) 2010 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (http://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the Simplified BSD License.
+
+
+
+Cain & Jevans                Standards Track                    [Page 1]
+
+RFC 5901                IODEF Phishing Extensions              July 2010
+
+
+Table of Contents
+
+   1. Introduction ....................................................3
+      1.1. Why a Common Report Format Is Needed .......................3
+      1.2. Processing of Exchanged Data Not Defined ...................4
+      1.3. Relation to the INCH IODEF Data Model ......................4
+   2. Terminology Used in This Document ...............................4
+      2.1. Requirements Language ......................................5
+   3. Interesting Fraud Event Data ....................................5
+      3.1. The Elements of a Phishing/Fraud Event .....................6
+      3.2. Useful Data Items in a Fraud Event .........................7
+   4. Fraud Activity Reporting via IODEF-Documents ....................8
+      4.1. Fraud Report Types .........................................8
+      4.2. Fraud Report XML Representation ............................9
+      4.3. Syntactical Correctness of Fraud Activity Reports ..........9
+   5. PhraudReport Element Definitions ...............................10
+      5.1. PhraudReport Structure ....................................10
+      5.2. Reuse of IODEF-Defined Elements ...........................11
+      5.3. Element and Attribute Specification Format ................11
+      5.4. Version Attribute .........................................12
+      5.5. FraudType Attribute .......................................12
+      5.6. PhishNameRef Element ......................................13
+      5.7. PhishNameLocalRef Element .................................13
+      5.8. FraudedBrandName Element ..................................13
+      5.9. LureSource Element ........................................14
+      5.10. OriginatingSensor Element ................................22
+      5.11. The DCSite Element .......................................23
+      5.12. TakeDownInfo Element .....................................25
+      5.13. ArchivedData Element .....................................27
+      5.14. RelatedData Element ......................................28
+      5.15. CorrelationData Element ..................................28
+      5.16. PRComments Element .......................................28
+      5.17. EmailRecord Element ......................................28
+   6. Mandatory IODEF and PhraudReport Elements ......................29
+      6.1. Guidance on Usage .........................................30
+   7. Security Considerations ........................................31
+      7.1. Transport-Specific Concerns ...............................31
+      7.2. Using the iodef:restriction Attribute .....................31
+   8. IANA Considerations ............................................32
+   9. Contributors ...................................................32
+   10. References ....................................................32
+      10.1. Normative References .....................................32
+      10.2. Informative References ...................................33
+   Appendix A.  Phishing Extensions XML Schema .......................34
+   Appendix B.  Example Virus Report .................................43
+      B.1.  Received Email ...........................................43
+      B.2.  Generated Report .........................................44
+
+
+
+
+Cain & Jevans                Standards Track                    [Page 2]
+
+RFC 5901                IODEF Phishing Extensions              July 2010
+
+
+   Appendix C.  Sample Phishing Report ...............................46
+      C.1.  Received Lure ............................................46
+      C.2.  Phishing Report ..........................................48
+
+1.  Introduction
+
+   Deception activities, such as receiving an email purportedly from a
+   bank requesting you to confirm your account information, are an
+   expanding attack type on the Internet.  The terms "phishing" and
+   "fraud" are used interchangeably in this document to characterize
+   broadly-launched social engineering attacks in which an electronic
+   identity is misrepresented in an attempt to trick individuals into
+   revealing their personal credentials (e.g., passwords, account
+   numbers, personal information, ATM PINs, etc.).  A successful
+   phishing attack on an individual allows the phisher (i.e., the
+   attacker) to exploit the individual's credentials for financial or
+   other gain.  Phishing attacks have morphed from directed email
+   messages from alleged financial institutions to more sophisticated
+   lures that may also include malware.
+
+   This document defines a data format extension to the Incident Object
+   Description Exchange Format (IODEF) [RFC5070] that can be used to
+   describe information about a phishing or other type of fraudulent
+   incident.  Sections 2 and 3 of this document provides an overview of
+   the terminology and process of a phishing event.  Section 4
+   introduces the high-level report format and how to use it.  Sections
+   5 and 6 describe the data elements of the fraud extensions.  The
+   appendices include an XML schema for the extensions and a few example
+   fraud reports.
+
+   The extensions defined in this document may be used to report the
+   social engineering victim lure, the collection site, credential
+   targeted ("spear") phishing, broad multi-recipient phishing, and
+   other evolving Internet-based fraud attempts.  Malware and other
+   malicious software included within the lure may also be included
+   within the report.
+
+1.1.  Why a Common Report Format Is Needed
+
+   To combat the rise in malicious activity on the Internet, service
+   providers and investigative agencies are sharing more and more
+   network and event data in a coordinated effort to identify
+   perpetrators and compromised accounts, coordinate responses, and
+   prosecute attackers.  As the number of data-sharing parties
+   increases, the number of party-specific tools, formats, and
+   definitions multiply rapidly until they overwhelm the investigative
+   and coordination abilities of those parties.
+
+
+
+
+Cain & Jevans                Standards Track                    [Page 3]
+
+RFC 5901                IODEF Phishing Extensions              July 2010
+
+
+   By using a common format, it becomes easier for an organization to
+   engage in this coordination as well as correlation of information
+   from multiple data sources or products into a cohesive view.  As the
+   number of data sources increases, a common format becomes even more
+   important, since multiple tools would be needed to interpret the
+   different sources of data.  A big win in a common format is the
+   ability to automate many of the analysis tasks and significantly
+   speed up the response and prosecution activities.
+
+1.2.  Processing of Exchanged Data Not Defined
+
+   While the intended use of this specification is to facilitate data
+   sharing between parties, the mechanics of this sharing process and
+   its related political challenges are out of scope for this document.
+
+1.3.  Relation to the INCH IODEF Data Model
+
+   Instead of defining a new report format, this document defines an
+   extension to [RFC5070].  The IODEF defines a flexible and extensible
+   format and supports a granular level of specificity.  These phishing
+   and fraud extensions reuse subsets of the IODEF data model and, where
+   appropriate, specify new data elements.  Leveraging an existing
+   specification allows for more rapid adoption and reuse of existing
+   tools in organizations.  For clarity, and in order to eliminate
+   duplication, only the additional structures necessary for describing
+   the exchange of phishing and e-crime activity are provided.
+
+2.  Terminology Used in This Document
+
+   Since many people use different but similar terms to mean the same
+   thing, we use the following terminology in this document.
+
+   a.  Phishing
+
+       The overall process of identifying victims, contacting them via a
+       lure, causing a victim to send a set of private credentials to a
+       collection site, and storing those credentials is called
+       phishing.
+
+   b.  Fraud Event
+
+       A fraud event is the combination of phishing and subsequent
+       fraudulent use of the private credentials.
+
+
+
+
+
+
+
+
+Cain & Jevans                Standards Track                    [Page 4]
+
+RFC 5901                IODEF Phishing Extensions              July 2010
+
+
+   c.  Lure
+
+       A lure is the decoy used to trick a victim into performing some
+       activity, such as providing their private credentials.  The lure
+       relies on social engineering concepts to convince the victim that
+       the lure is genuine and its instructions should be followed.  A
+       lure includes a pointer or link to a collection site.
+
+   d.  Collection Site
+
+       The website, email box, SMS number, phone number, or other place
+       where a phished victim sends their private credentials for later
+       fraudulent use by a criminal.
+
+   e.  Credentials
+
+       A credential is data that is transferred or presented to
+       establish either a claimed identity or the authorizations of a
+       system entity.  Many websites require a user name and password --
+       combined, they are a credential -- to access sensitive content.
+
+   f.  Message
+
+       Although primarily email, a lure can be transported via any
+       messaging medium, such as instant messages, Voice over IP (VoIP),
+       or text via an SMS service.  The term "message" is used as a
+       generic term for any of these transport mediums.
+
+2.1.  Requirements Language
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in RFC 2119 [RFC2119].
+
+3.  Interesting Fraud Event Data
+
+   Before defining the structure of the IODEF extensions, we identify
+   the "interesting" data in phishing and other fraudulent activities.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Cain & Jevans                Standards Track                    [Page 5]
+
+RFC 5901                IODEF Phishing Extensions              July 2010
+
+
+3.1.  The Elements of a Phishing/Fraud Event
+
+   +-----------+        +------------------+
+   | Fraudster |<---<-- | Collection Site  |<---O--<----<----+
+   +----+------+        +------------------+    |            |
+        |                                       |            |
+        |                                    +--|-----+      ^
+        |                                    | Sensor | Credentials
+        |                                    +-|------+      |
+        |      +---------------+               |        +-------+
+        \--->--| Attack Source |--Lure--->-----O------> | User/ |
+               +---------------+                        |Victim |
+                                                        +-------+
+
+            Figure 3.1.  The Components of Internet Fraud
+
+   Internet-based phishing and fraud activities are normally comprised
+   of at least six components:
+
+   1.  The phisher, fraudster, or party perpetrating the fraudulent
+       activity.  Most times this party is not readily identifiable.
+
+   2.  The attack source -- the source of the phishing email, virus,
+       trojan, or other attack -- is masked in an enticing manner.
+
+   3.  The lure used to trick the victim into responding.
+
+   4.  The user, victim, or intended target of the fraud or phish.
+
+   5.  The credentials, personal data, or other information the victim
+       has surrendered to the phisher.
+
+   6.  The collection site, where the victim sends their credentials or
+       personal data if they have been duped by the lure of the phisher.
+       This may be a website, mailbox, phone operator, or database.
+
+   If we take a holistic view of the attack, there are some additional
+   components:
+
+   o  The sensor -- the means by which the phish is detected.  This
+      element may be an intrusion detection system, firewall, filter,
+      email gateway, or human analyst.
+
+   o  A forensic or archive site (not pictured), where an investigator
+      has copied or otherwise retained the data used for the fraud
+      attempt or credential collection.
+
+
+
+
+
+Cain & Jevans                Standards Track                    [Page 6]
+
+RFC 5901                IODEF Phishing Extensions              July 2010
+
+
+3.1.1.  Fraudulent Activity Extensions to the IODEF-Document
+
+   Fraud events are reported in a fraud activity report, which is an
+   instance of an XML IODEF-Document Incident element with added
+   EventData and AdditionalData elements.  The additional fields in the
+   EventData specific to phishing and fraud are enclosed in a
+   PhraudReport XML element.  Fraudulent activity may include multiple
+   emails, instant messages, or network messages, scattered over various
+   times, locations, and methodologies.  The PhraudReport within an
+   EventData may include information about the email header and body,
+   details of the actual phishing lure, correlation to other attacks,
+   and details of the removal of the web server or credential collector.
+   As a phishing attack may generate multiple reports to an incident
+   team, multiple PhraudReports may be combined into one EventData
+   structure, and multiple EventData structures may be combined into one
+   incident report.  One IODEF incident report may record one or more
+   individual phishing events and may include multiple EventData
+   elements.
+
+   This document defines new extension elements for the EventData IODEF
+   XML elements and identifies those required in a PhraudReport.  The
+   appendices contain sample fraud activity reports and a complete
+   schema.
+
+   The IODEF Extensions defined in this document comply with Section 4,
+   "Extending the IODEF Format" in [RFC5070].
+
+3.2.  Useful Data Items in a Fraud Event
+
+   There are a number of subtle and non-obvious data to capture from a
+   fraud event that make the event analysis and correlation with other
+   events more useful.  These data can be grouped into categories:
+
+3.2.1.  Data about the Lure
+
+   If a lure was presented as part of the fraud event, this category
+   includes the original received lure, the means by which the lure was
+   received (e.g., email, phone, or SMS), and the source addresses that
+   sent the lure.  Other useful data includes DNS data about the lure
+   source, identification of any accompanying malware, and the brand
+   name defrauded.
+
+3.2.2.  Credential Collection Site Data
+
+   The collection site contains victim identifications, along with
+   copies of data supplied by the victims, such as account names or
+   numbers, passwords, dates of birth, etc.  This category of useful
+   data includes these credentials, along with information about the
+
+
+
+Cain & Jevans                Standards Track                    [Page 7]
+
+RFC 5901                IODEF Phishing Extensions              July 2010
+
+
+   collection site itself, such as its type, site DNS data, DNS
+   registrant data, and site physical location.  The location and
+   registrant information is particularly important if law enforcement
+   assistance is expected.  Additionally, an entire site archive can be
+   gathered to allow a collector on a shared website to be disabled
+   without impacting other users.
+
+3.2.3.  Detection Information
+
+   This is a non-obvious data category and contains data on how the lure
+   or collection site was detected.  Understanding how the lure was
+   detected allows us to design and implement better detection systems.
+
+3.2.4.  Analysis Output
+
+   In an environment where time is critical, it is imperative that
+   analysis from one party can be reliably explained to and shared with
+   other investigative parties.  This grouping includes data that an
+   investigator found interesting or could be useful to others.
+
+4.  Fraud Activity Reporting via IODEF-Documents
+
+   A fraud activity report is an instance of an XML IODEF-Document with
+   additional extensions and usage guidance, as specified in Section 4
+   of this document.  These additional extensions are implemented
+   through the PhraudReport XML element.
+
+   As described in the following subsections, reporting fraud activity
+   has three primary components: choosing a report type, a format for
+   the data, and how to check the correctness of the format.
+
+4.1.  Fraud Report Types
+
+   There are three actions relating to reporting phishing events.
+   First, a reporter may *create* and exchange a new report on a new
+   event.  Secondly, a reporter may *update* a previously exchanged
+   report to indicate new collection sites, site takedown information,
+   or related activities.  Lastly, a reporter may have realized that the
+   report is in error or contains significant incorrect data and that
+   the prudent reaction is to *delete* the report.
+
+   The three types of reports are denoted through the use of the
+   ext-purpose attribute of an Incident element.  A new report contains
+   an empty or a "create" ext-purpose value; an updated report contains
+   an ext-value value of "update"; a request for deletion contains a
+   "delete" ext-purpose value.  Note that this is actually an advisory
+   marking for the report originator or recipient, as operating
+   procedures in a report life cycle are very environment specific.
+
+
+
+Cain & Jevans                Standards Track                    [Page 8]
+
+RFC 5901                IODEF Phishing Extensions              July 2010
+
+
+4.2.  Fraud Report XML Representation
+
+   The IODEF Incident element ([RFC5070], Section 3.2) is summarized
+   below.  It and the rest of the data model presented in Section 4 is
+   expressed in Unified Modeling Language (UML) syntax as used in the
+   IODEF specification.  The UML representation is for illustrative
+   purposes only; elements are specified in XML as defined in
+   Appendix A.
+
+   +--------------------+
+   | Incident           |
+   +--------------------+
+   | ENUM purpose       |<>----------[ IncidentID ]
+   | STRING ext-purpose |<>--{0..1}--[ AlternativeID ]
+   | ENUM lang          |<>--{0..1}--[ RelatedActivity ]
+   | ENUM restriction   |<>--{0..1}--[ DetectTime ]
+   |                    |<>--{0..1}--[ StartTime ]
+   |                    |<>--{0..1}--[ EndTime ]
+   |                    |<>----------[ ReportTime ]
+   |                    |<>--{0..*}--[ Description ]
+   |                    |<>--{1..*}--[ Assessment ]
+   |                    |<>--{0..*}--[ Method ]
+   |                    |<>--{1..*}--[ Contact ]
+   |                    |<>--{0..*}--[ EventData ]
+   |                    |              |<>--[ AdditionalData ]
+   |                    |                     |<>--[ PhraudReport ]
+   |                    |<>--{0..1}--[ History ]
+   |                    |<>--{0..*}--[ AdditionalData ]
+   +------------------+
+
+           Figure 4.1.  The IODEF XML Incident Element (Modified)
+
+   A fraud activity report is composed of one iodef:Incident element
+   that contains one or more related PhraudReport elements embedded in
+   the iodef:AdditionalData element of iodef:EventData.  The
+   PhraudReport element is added to the IODEF using its defined
+   extension procedure documented in Section 5 of [RFC5070].
+
+   One IODEF-Document may contain information on multiple incidents with
+   information for each incident contained within an iodef:Incident
+   element ([RFC5070], Section 3.12).
+
+4.3.  Syntactical Correctness of Fraud Activity Reports
+
+   The fraud activity report MUST pass XML validation using the schema
+   defined in [RFC5070] and the extensions defined in Appendix A of this
+   document.
+
+
+
+
+Cain & Jevans                Standards Track                    [Page 9]
+
+RFC 5901                IODEF Phishing Extensions              July 2010
+
+
+5.  PhraudReport Element Definitions
+
+   A PhraudReport consists of an extension to the
+   Incident.EventData.AdditionalData element with a dtype of "xml".  The
+   elements of the PhraudReport will specify information about the six
+   components of fraud activity identified in Section 3.1.  Additional
+   forensic information and commentary can be added by the reporter as
+   necessary to show relation to other events, to show the output of an
+   investigation, or for archival purposes.
+
+5.1.  PhraudReport Structure
+
+   A PhraudReport element is structured as follows.  The components of a
+   PhraudReport are introduced in functional grouping, as some
+   parameters are related and some elements may not make sense
+   individually.
+
+   +------------------+
+   |   PhraudReport   |
+   +------------------+
+   | STRING Version   |<>--{0..1}--[ PhishNameRef ]
+   | ENUM FraudType   |<>--{0..1}--[ PhishNameLocalRef ]
+   | STRING ext-value |<>--{0..1}--[ FraudParameter ]
+   |                  |<>--{0..*}--[ FraudedBrandName ]
+   |                  |<>--{1..*}--[ LureSource ]
+   |                  |<>--{1..*}--[ OriginatingSensor ]
+   |                  |<>--{0..1}--[ EmailRecord ]
+   |                  |<>--{0..*}--[ DCSite ]
+   |                  |<>--{0..*}--[ TakeDownInfo ]
+   |                  |<>--{0..*}--[ ArchivedData ]
+   |                  |<>--{0..*}--[ RelatedData ]
+   |                  |<>--{0..*}--[ CorrelationData ]
+   |                  |<>--{0..1}--[ PRComments ]
+   +------------------+
+
+           Figure 5.1.  The PhraudReport Element
+
+   Relevant information about a phishing or fraud event is encoded into
+   six components as follows:
+
+   a.  The PhishNameRef and PhishNameLocalRef elements identify the
+       fraud or class of fraud.
+
+   b.  The LureSource element describes the source of the attack or
+       phishing lure, including host information and any included
+       malware.
+
+
+
+
+
+Cain & Jevans                Standards Track                   [Page 10]
+
+RFC 5901                IODEF Phishing Extensions              July 2010
+
+
+   c.  The DCSite element describes the technical details of the
+       credential collection site.
+
+   d.  The OriginatingSensor element describes the means of detection.
+
+   The RelatedData, ArchivedData, and TakeDownInfo fields allow optional
+   forensics and history data to be included.
+
+   A specific phish/fraud activity can be identified using a combination
+   of the FraudType, FraudParameter, FraudedBrandName, LureSource, and
+   PhishNameRef elements.
+
+5.2.  Reuse of IODEF-Defined Elements
+
+   Elements, attributes, and parameters defined in the base IODEF
+   specification were used whenever possible in the definition of the
+   PhraudReport XML element.  This specification does not introduce any
+   new variable types or encodings to the IODEF data model, but extends
+   the IODEF Contact and System elements.
+
+   The data model schema contains a copy of the iodef:System element.
+   Although we would like to just extend the System element, it is
+   defined in RFC 5070 with an unable-to-extend anonymous type, so we
+   copied the element, named its underlying type, and then generated the
+   extension to it.
+
+   Note: Elements that are imported from the base IODEF specification
+   are prefaced with an "iodef" XML namespace and are noted with the
+   section defining that element in [RFC5070].  Each element in a
+   PhraudReport is used as described in the following sections.
+
+5.3.  Element and Attribute Specification Format
+
+   The following sections describe the components of a PhraudReport XML
+   element.  Each description is structured as follows.
+
+   1.  A terse XML-type identifier for the element or attribute.
+
+   2.  An indication of whether the element or attribute is REQUIRED or
+       optional.  Mandatory items are noted as REQUIRED.  If not
+       specified, elements are optional.  Note that when optional
+       elements are included, they may REQUIRE specific sub-elements.
+
+   3.  A description of the element or attribute and its intended use.
+
+
+
+
+
+
+
+Cain & Jevans                Standards Track                   [Page 11]
+
+RFC 5901                IODEF Phishing Extensions              July 2010
+
+
+   Elements that contain sub-elements or enumerated values are further
+   sub-sectioned.  Note that there is no "trickle-up" effect in
+   elements.  That is, the required elements of a sub-element are only
+   populated if the sub-element is used.
+
+5.4.  Version Attribute
+
+   REQUIRED.  STRING.  The version shall be the value 0.06, to be
+   compliant with this document.
+
+5.5.  FraudType Attribute
+
+   REQUIRED.  One ENUM.  The FraudType attribute describes the type of
+   fraudulent activity described in this PhraudReport.  The FraudType
+   chosen determines the value of the FraudParameter filed.  This field
+   contains one of the following values:
+
+   1.  phishing.  The FraudParameter should be the subject line of the
+       phishing lure email or value of a lure IM or VoIP message.  This
+       type is a standard phishing lure, usually sent as email, and is
+       intended to exploit the recipient's credentials for financial
+       gain.
+
+   2.  recruiting.  The FraudParameter is the subject line of the
+       recruit, or mule, email or message.
+
+   3.  malware distribution.  The FraudParameter is the email subject
+       line of the phishing email.  This type of email phish does not
+       pose a risk of financial loss to the recipient, but lures the
+       recipient to an infected site.
+
+   4.  fraudulent site.  This identifies a known fraudulent site that
+       does not necessarily send spam but is used to show lures.  The
+       FraudParameter may be used to identify the website.
+
+   5.  dnsspoof.  This choice does not have a related FraudParameter.
+       This value is used when a DNS system component responds with an
+       untrue IP address for the requested domain name due to either
+       cache poisoning, ID spoofing, or other manipulation of the DNS
+       system.
+
+   6.  archive.  There is no required FraudParameter for this choice,
+       although the FraudParameter of the original phish could be
+       entered.  The data archived from the phishing server is placed in
+       the ArchivedData element.
+
+   7.  other.  This is used to identify not-yet-enumerated fraud types.
+
+
+
+
+Cain & Jevans                Standards Track                   [Page 12]
+
+RFC 5901                IODEF Phishing Extensions              July 2010
+
+
+   8.  unknown.  This choice may have an associated FraudParameter.  It
+       is used to cover confused cases.
+
+   9.  ext-value.  This choice identifies an unidentified FraudType.
+       The FraudType should be captured in the ext-value attribute.
+
+5.5.1.  ext-value Attribute
+
+   OPTIONAL.  This STRING may be populated with a FraudType that has not
+   been predefined.
+
+5.5.2.  FraudParameter Element
+
+   Zero or one value of iodef:MLStringType.  The contents of this
+   element are dependent on the FraudType choice.  It may be an email
+   subject line, VoIP lure, link in an IM message, or a web URL.  Note
+   that some phishers add a number of random characters onto the end of
+   a phish email subject line for uniqueness; reporters should delete
+   those characters before insertion into the FraudParameter field.
+
+5.6.  PhishNameRef Element
+
+   Zero or one value of iodef:MLStringType.  The PhishNameRef element is
+   the common name used to identify this fraud event.  It is often the
+   name agreed upon by involved parties or vendors.  Using this name can
+   be a convenient way to reference the activity when collaborating with
+   other parties, the media, or engaging in public education.
+
+5.7.  PhishNameLocalRef Element
+
+   Zero or one value of iodef:MLStringType.  The PhishNameLocalRef
+   element describes a local name or Unique-IDentifier (UID) that is
+   used by various parties before a commonly agreed-upon term is
+   adopted.  This field allows a cross-reference from the submitting
+   organization's system to a central repository.
+
+5.8.  FraudedBrandName Element
+
+   Zero or more values of iodef:MLStringType.  This is the identifier of
+   the recognized brand name or company name used in the phishing
+   activity (e.g., XYZ Semiconductor Corp).
+
+
+
+
+
+
+
+
+
+
+Cain & Jevans                Standards Track                   [Page 13]
+
+RFC 5901                IODEF Phishing Extensions              July 2010
+
+
+5.9.  LureSource Element
+
+   REQUIRED.  One or more values.  The LureSource element describes the
+   source of the PhraudReport lure.  It allows the specification of IP
+   addresses, DNS names, domain registry information, and rudimentary
+   support for the files that might be downloaded or registry keys
+   modified by the crimeware.
+
+   +-------------+
+   | LureSource  |
+   +-------------+
+   |             |<>--(1..*)--[ System ]
+   |             |<>--(0..*)--[ DomainData ]
+   |             |<>--(0..1)--[ IncludedMalware  ]
+   |             |<>--(0..1)--[ FilesDownloaded  ]
+   |             |<>--(0..1)--[ WindowsRegistryKeysModified  ]
+   +-------------+
+
+           Figure 5.2.  The LureSource Element
+
+5.9.1.  System Element
+
+   REQUIRED.  One or more values of the iodef:System ([RFC5070],
+   Section 3.15).  The system element describes a particular host
+   involved in the phishing activity.  If the real IP address can be
+   ascertained, it should be populated.  A spoofed address may also be
+   entered, and the spoofed attribute SHALL be set.
+
+   Multiple System elements may be used to identify the DNS name and IP
+   address(es) of the lure source.
+
+5.9.2.  DomainData Element
+
+   Zero or more element values.  The DomainData element describes the
+   registration, delegation, and control of a domain used to source the
+   lure and can identify the IP address associated with the System
+   element URI.  Capturing the domain data is very useful when
+   investigating or correlating events.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Cain & Jevans                Standards Track                   [Page 14]
+
+RFC 5901                IODEF Phishing Extensions              July 2010
+
+
+   The structure of a DomainData element is as follows:
+
+   +--------------------+
+   | DomainData         |
+   +--------------------+
+   |                    |<>----------[ Name ]
+   |                    |<>--(0..1)--[ DateDomainWasChecked ]
+   | ENUM SystemStatus  |<>--(0..1)--[ RegistrationDate ]
+   | ENUM DomainStatus  |<>--(0..1)--[ ExpirationDate ]
+   |                    |<>--(0..*)--[ Nameservers ]
+   |                    |<>--(0..1)--[ DomainContacts ]
+   +--------------------+
+
+                Figure 5.3.  The DomainData Element
+
+5.9.2.1.  Name Element
+
+   REQUIRED.  One value of iodef:MLStringType.  The Name element
+   contains the host DNS name used in this event.  Its value should be
+   the complete DNS host address; e.g., if an event targeted
+   www.example.com, the value would be www.example.com.
+
+5.9.2.2.  DateDomainWasChecked Element
+
+   Zero or one value of DATETIME.  This element includes the timestamp
+   of when this domain data was checked and entered into this report, as
+   many phishers modify their domain data at various stages of a
+   phishing event.
+
+5.9.2.3.  RegistrationDate Element
+
+   Zero or one value of DATETIME.  The RegistrationDate element shows
+   the date of registration for a domain.
+
+5.9.2.4.  ExpirationDate Element
+
+   Zero or one value of DATETIME.  The ExpirationDate element shows the
+   date the domain will expire.
+
+5.9.2.5.  Nameservers Element
+
+   Zero or more values.  These fields hold nameservers identified for
+   this domain.  Each entry is a sequence of DNSNameType and iodef:
+   Address pairs, as specified below.
+
+
+
+
+
+
+
+Cain & Jevans                Standards Track                   [Page 15]
+
+RFC 5901                IODEF Phishing Extensions              July 2010
+
+
+   +--------------------+
+   | Nameservers        |
+   +--------------------+
+   |                    |<>----------[ Server]
+   |                    |<>--(1..*)--[ iodef:Address ]
+   +--------------------+
+
+                Figure 5.4.  The Nameservers Element
+
+   The use of one Server value and multiple Address values is used to
+   note multiple IP addresses associated with one DNS entry for the
+   domain nameserver.
+
+5.9.2.5.1.  Server Element
+
+   One value of iodef:MLStringType.  This field contains the DNS name of
+   the domain nameserver.
+
+5.9.2.5.2.  iodef:Address Element
+
+   One or more values of iodef:Address.  This field lists the IP
+   address(es) associated with this Server element.
+
+5.9.2.6.  DomainContacts Element
+
+   REQUIRED.  Choice of either a SameDomainContact or one or more
+   Contact elements.  The DomainContacts element allows the reporter to
+   enter contact information supplied by the registrar or returned by
+   whois queries.  For efficiency of the reporting party, the domain
+   contact information may be marked to be the same as another domain
+   already reported using the SameDomainContact element.
+
+   +----------------+
+   | DomainContacts |
+   +----------------+
+   |                |<>--(0..1)--[ SameDomainContact ]
+   |                |<>--(1..*)--[ Contact ]
+   +----------------|
+
+             Figure 5.5.  The DomainContacts Element
+
+5.9.2.6.1.  SameDomainContact Element
+
+   REQUIRED.  One iodef:MLStringType.  The SameDomainContact element is
+   populated with a domain name if the contact information for this
+   domain is identical to that name in this or another report.
+   Implementors are cautioned to only use this element when the domain
+   contact data returned by a registrar or registry is identical.
+
+
+
+Cain & Jevans                Standards Track                   [Page 16]
+
+RFC 5901                IODEF Phishing Extensions              July 2010
+
+
+5.9.2.6.2.  Contact Element
+
+   REQUIRED.  One or more iodef:Contact elements.  This element reuses
+   and extends the iodef:Contact elements for its components.  Each
+   component may have zero or more values.  If only the role attribute
+   and the ContactName component are populated, the same (identical)
+   information is listed for multiple roles.
+
+   +--------------------+
+   | Contact            |
+   +--------------------+
+   |                    |<>----------[ iodef:ContactName ]
+   |                    |<>--(0..*)--[ iodef:Description ]
+   | ENUM role          |<>--(0..*)--[ iodef:RegistryHandle ]
+   |                    |<>--(0..1)--[ iodef:PostalAddress ]
+   | ENUM restriction   |<>--(0..*)--[ iodef:Email ]
+   | STRING ext-role    |<>--(0..*)--[ iodef:Telephone ]
+   | ENUM type          |<>--(0..1)--[ iodef:Fax ]
+   | STRING ext-type    |<>--(0..1)--[ iodef:Timezone ]
+   |                    |<->----------[ AdditionalData ]
+   |                    |                  +<-> [ Confidence ]
+   +--------------------+
+
+           Figure 5.6.  The Contact Element
+
+   Each Contact has optional attributes to capture the sensitivity and
+   role for which the contact is listed.  Elements reused from [RFC5070]
+   are not discussed in this document.
+
+5.9.2.6.2.1.  Confidence Element
+
+   REQUIRED.  ENUM.  The Confidence element describes a qualitative
+   assessment of the veracity of the contact information.  This
+   attribute is an extension to the iodef:Contact element and is defined
+   in this document.  There are five possible Confidence values, as
+   follows.
+
+   1.  known-fraudulent.  This contact information has been previously
+       determined to be fraudulent, as either non-existent physical
+       information or containing real information not associated with
+       this domain registration.
+
+   2.  looks-fraudulent.  The contact information has suspicious
+       information included.
+
+   3.  known-real.  The contact information has been previously
+       investigated or determined to be correct.
+
+
+
+
+Cain & Jevans                Standards Track                   [Page 17]
+
+RFC 5901                IODEF Phishing Extensions              July 2010
+
+
+   4.  looks-real.  The contact information does not arouse suspicion
+       but has not been previously validated.
+
+   5.  unknown.  The reporter cannot make a value judgment on the
+       contact data.
+
+5.9.2.6.2.2.  ext-role Attribute
+
+   REQUIRED.  ENUM.  The ext-role attribute is extended from the iodef:
+   ext-role attribute with values identified in RFC 3982 [RFC3982].  The
+   ext-value value of the role attribute should be used, with the
+   ext-role attribute value chosen from one of the following values:
+
+   1.  billingContacts
+
+   2.  technicalContacts
+
+   3.  administrativeContacts
+
+   4.  legalContacts
+
+   5.  zoneContacts
+
+   6.  abuseContacts
+
+   7.  securityContacts
+
+   8.  otherContacts
+
+   9.  hostingProvider.  This contact is the hosting provider of this
+       server.  Although not in RFC 3982, it is useful in investigations
+       to note where the server is located and who operates it.  Load-
+       balanced, multicast, or anycast servers may have multiple
+       hostingProvider contact entries.
+
+5.9.3.  SystemStatus Attribute
+
+   REQUIRED.  ENUM.  The SystemStatus attribute assesses a system's
+   involvement in this event.  The value is chosen from this list:
+
+   1.  spoofed.  This domain or system did not participate in this
+       event, but its address space or DNS name was simply used by
+       another party.
+
+   2.  fraudulent.  The system is operated with fraudulent intentions,
+       e.g., the domain name is a homophone.
+
+
+
+
+
+Cain & Jevans                Standards Track                   [Page 18]
+
+RFC 5901                IODEF Phishing Extensions              July 2010
+
+
+   3.  innocent-hacked.  The system was compromised by a third party and
+       used in this event.
+
+   4.  innocent-hijacked.  The IP address or domain name was
+       deliberately hijacked via BGP or DNS and used in this event to
+       source the lure or host the collection site.
+
+   5.  unknown.  No conclusions are inferred from this event.
+
+5.9.4.  DomainStatus Attribute
+
+   ENUM.  The DomainStatus attribute describes the registry status of a
+   domain at the time of the report.  The following enumerated list is
+   taken from the "domainStatusType" of [RFC3982].  An extra "unknown"
+   value was added in case the status is indeterminable.
+
+   1.   reservedDelegation
+
+   2.   assignedAndActive
+
+   3.   assignedAndInactive
+
+   4.   assignedAndOnHold
+
+   5.   revoked
+
+   6.   transferPending
+
+   7.   registryLock
+
+   8.   registrarLock
+
+   9.   other
+
+   10.  unknown
+
+5.9.5.  IncludedMalware Element
+
+   Zero or one value.  The IncludedMalware element allows for the
+   identification and optional inclusion of the actual malware that was
+   part of the lure.  The goal of this element is not to detail the
+   characteristics of the malware but rather to allow for a convenient
+   element to link malware to a phishing campaign.
+
+
+
+
+
+
+
+
+Cain & Jevans                Standards Track                   [Page 19]
+
+RFC 5901                IODEF Phishing Extensions              July 2010
+
+
+   +------------------+
+   | IncludedMalware  |
+   +------------------+
+   |                  |<>--(1..*)--[ Name ]
+   |                  |<>--(0..1)--[ ds:Reference ]
+   |                  |<>--(0..1)--[ Data ]
+   +------------------+
+
+   +-----------------------+
+   | Data                  |
+   +-----------------------+
+   | hexBinary XORPattern  |
+   +-----------------------+
+
+       Figure 5.7.  The IncludedMalware Element
+
+5.9.5.1.  Name Element
+
+   REQUIRED.  One or more values of iodef:MLStringType.  This field is
+   used to identify the lure malware by its known name.  Unnamed malware
+   may be identified by a value of "unknown".
+
+5.9.5.2.  Reference Element
+
+   Zero or one value of the Reference.  This optional field is used to
+   hold the algorithm identification and value of a hash computed over
+   the malware executable.  This entire element is imported from
+   [RFC3275].  Implementations SHOULD support the use of SHA-1 [SHA] as
+   a DigestMethod.
+
+5.9.5.3.  Data Element
+
+   Zero or one value.  The optional Data element is used to include the
+   lure malware, which is encoded as a hexBinary type and XORed with a
+   pattern to render it harmless.
+
+5.9.5.3.1.  XORPattern Attribute
+
+   One value of hexBinary.  The Data element includes a 16-hexadecimal-
+   character XORPattern attribute to support disabling the included
+   malware to bypass anti-virus filters.  The default value is
+   0x55AA55AA55AA55BB, which would be XORed with the malware datastring
+   to recover the actual malware.
+
+
+
+
+
+
+
+
+Cain & Jevans                Standards Track                   [Page 20]
+
+RFC 5901                IODEF Phishing Extensions              July 2010
+
+
+5.9.6.  FilesDownloaded Element
+
+   Zero or one value of a sequence of File elements.
+
+   +---------------------+
+   | FilesDownloaded     |
+   +---------------------+
+   |                     |<>--(1..*)--[ File ]
+   +---------------------+
+
+       Figure 5.8.  The FilesDownloaded Element
+
+5.9.6.1.  File Element
+
+   One or more values of iodef:MLStringType.  The File element value is
+   the name of a file downloaded by this lure.
+
+5.9.7.  WindowsRegistryKeysModified Element
+
+   One or more values of the Key sequence.  The contents of the
+   WindowsRegistryKeysModified element are sequences of Key elements.
+
+   +------------------------------+
+   | WindowsRegistryKeysModified  |
+   +------------------------------+
+   |                              |<>--(1..*)--[ Key ]
+   +------------------------------+
+
+   +--------------+
+   | Key          |
+   +--------------+
+   |              |<>-----[ Name ]
+   |              |<>-----[ Value ]
+   +--------------+
+
+       Figure 5.9.  The WindowsRegistryKeysModified Element
+
+5.9.7.1.  Key Element
+
+   One or more sequences.  The Key element is a sequence of Name and
+   Value pairs representing an operating system registry key and its
+   value.  The key and value are encoded as in Microsoft .reg files
+   [KB310516].
+
+
+
+
+
+
+
+
+Cain & Jevans                Standards Track                   [Page 21]
+
+RFC 5901                IODEF Phishing Extensions              July 2010
+
+
+5.9.7.1.1.  Name Element
+
+   One STRING, representing the Windows Operating System Registry Key
+   Name.  The value is encoded as in Microsoft .reg files, e.g.,
+   [HKEY_LOCAL_MACHINE\Software\Test\KeyName].
+
+5.9.7.1.2.  Value Element
+
+   One STRING, representing the value of the associated Key encoded as
+   in Microsoft .reg files, e.g., REG_BINARY:01.
+
+5.10.  OriginatingSensor Element
+
+   REQUIRED.  The OriginatingSensor element contains the identification
+   and cognizant data of the network element that detected this fraud
+   activity.  Note that the network element does not have to be on the
+   Internet itself (i.e., it may be a local Intrusion Detection System
+   (IDS)), nor is it required to be mechanical (e.g., humans are
+   allowed).
+
+   Multiple OriginatingSensor elements are allowed to support detection
+   at multiple locations.
+
+   +----------------------------+
+   | OriginatingSensor          |
+   +----------------------------+
+   | ENUM OriginatingSensorType |<>------------[ DateFirstSeen ]
+   |                            |<>--(1..*)----[ iodef:System ]
+   +----------------------------+
+
+           Figure 5.10.  The OriginatingSensor Element
+
+   The OriginatingSensor requires a type value and identification of the
+   entity that detected this fraudulent event.
+
+5.10.1.  OriginatingSensorType Attribute
+
+   REQUIRED.  ENUM.  The value is chosen from the following list,
+   categorizing the function of this sensor:
+
+   1.  web.  A web server or service detected this event.
+
+   2.  webgateway.  A proxy, firewall, or other network gateway detected
+       this event.
+
+   3.  mailgateway.  The event was detected via a mail gateway or
+       filter.
+
+
+
+
+Cain & Jevans                Standards Track                   [Page 22]
+
+RFC 5901                IODEF Phishing Extensions              July 2010
+
+
+   4.  browser.  The event was detected at the user web interface or
+       browser-type element.
+
+   5.  ispsensor.  The event was detected by an automated system in the
+       network, such as Intrusion Detection System, Intrusion Protection
+       System, or other Internet Service Provider device.
+
+   6.  human.  A non-automated system (e.g., a human, manual analysis,
+       etc.) detected this event.
+
+   7.  honeypot.  The event was detected by receipt at a decoy device.
+
+   8.  other.  The detection was performed via a non-listed method.
+
+5.10.2.  DateFirstSeen Element
+
+   REQUIRED.  DATETIME.  This is the date and time that this sensor
+   first saw this phishing activity.
+
+5.10.3.  iodef:System Element
+
+   REQUIRED.  One or more values of iodef:System.  This is
+   identification information (such as the IP version, IP address, etc.)
+   of the entity that detected this event.  The ability to identify
+   multiple detectors is supported.
+
+5.11.  The DCSite Element
+
+   Zero or more DCSite elements.  The DCSite captures the type,
+   identifier, location, and other pertinent information about the
+   credential gathering process, or data collection site, used in the
+   phishing incident.  The data collection site is identified by four
+   elements: the type of collector, the network location, information
+   about its DNS domain, and a confidence factor.  Further details about
+   the domain, system, or owner of the DCSite can be inserted into the
+   DomainData sub-element.
+
+   If the DCSite element is present, a value is required.  Multiple
+   DCSite elements are allowed to indicate multiple collection sites for
+   a single collector.  Multiple URLs pointing to the same DNS entry can
+   be identified with multiple SiteURL elements.
+
+
+
+
+
+
+
+
+
+
+Cain & Jevans                Standards Track                   [Page 23]
+
+RFC 5901                IODEF Phishing Extensions              July 2010
+
+
+   +--------------+
+   | DCSite       |
+   +--------------+
+   | ENUM DCType  |<>--+--------[ SiteURL ]
+   |              |    +--------[ Domain ]
+   |              |    +--------[ EmailSite ]
+   |              |    +--------[ System ]
+   |              |    +--------[ Unknown ]
+   |              |<>--(0..*)---[ iodef:Node ]
+   |              |<>--(0..1)---[ DomainData ]
+   |              |<>--(0..1)---[ iodef:Assessment ]
+   +--------------+
+
+        Figure 5.11.  The DCSite Element
+
+5.11.1.  DCType Attribute
+
+   REQUIRED.  ENUM.  The DCType attribute identifies the method of data
+   collection as determined through the analysis of the victim computer,
+   lure, or malware.  This attribute coupled with the DCSite content
+   identifies the data collection site.
+
+   1.  web.  The user is redirected to a website to collect the data.
+
+   2.  email.  The victim sends an email with credentials enclosed.
+
+   3.  keylogger.  Some form of keylogger is downloaded to the victim.
+
+   4.  automation.  Other forms of automatic data collection, such as
+       background Object Linking and Embedding (OLE) automation, are
+       used to capture information on the user's machine.
+
+   5.  unspecified.
+
+5.11.2.  DCSite Values
+
+   REQUIRED.  The DCSite element contains the IP address, URL, email
+   site, or other identifier of the credential or data collection site.
+   The Domain choice may be used to identify entire "phishy" domains
+   like those used for the RockPhish and related malware.  Each DCSite
+   element also includes a confidence attribute to convey the reporter's
+   assessment of their confidence that this DCSite element is valid and
+   involved with this event.  The confidence value is a per-DCSite
+   value, as multiple-site data collectors may have different confidence
+   values.
+
+
+
+
+
+
+Cain & Jevans                Standards Track                   [Page 24]
+
+RFC 5901                IODEF Phishing Extensions              July 2010
+
+
+   The DCSite element is a choice of:
+
+   1.  SiteURL.  One value of iodef:MLStringType.  This choice supports
+       URIs and other web-based identifiers.
+
+   2.  Domain.  One value of iodef:MLStringType.  This choice allows the
+       entry of a DNS domain name.
+
+   3.  EmailSite.  One value of iodef:MLStringType.  This choice
+       includes an email address if the site used email communications.
+
+   4.  iodef:Address.  One value of iodef:Address element.  This choice
+       is used to capture the IP address of a site.
+
+   5.  Unknown.  One value of iodef:MLStringType.  The unknown entry is
+       used for exceptions to the preceding choices.
+
+5.11.2.1.  Confidence Attribute
+
+   One value of INTEGER.  The confidence attribute is a value between 0
+   and 100, representing the reporter's certainty that this is a genuine
+   phishing site.  A value of 0 represents a false positive; a value of
+   100 signifies that the reporter has independently verified this site.
+
+5.11.3.  iodef:Node Element
+
+   Zero or more values of iodef:Node.  This element is used to identify
+   the IP address(es) or DNS names associated with the DCSite element
+   value.
+
+5.11.4.  DomainData Element
+
+   Zero or one value of DomainData (Section 5.9.2).  This element allows
+   for the identification of data associated with the data collection
+   site.
+
+5.11.5.  iodef:Assessment Element
+
+   Zero or one value of iodef:Assessment.  This element is used to
+   designate different confidence levels of multiple-site data
+   collectors.
+
+5.12.  TakeDownInfo Element
+
+   Zero or more TakeDownInfo elements.  This element identifies the
+   agent or agency that performed the removal, DNS domain disablement,
+   or ISP-blockage of the phish or fraud collector site.  A PhraudReport
+   may have multiple TakeDownInfo elements to support activities where
+
+
+
+Cain & Jevans                Standards Track                   [Page 25]
+
+RFC 5901                IODEF Phishing Extensions              July 2010
+
+
+   multiple takedown activities are involved on different dates.  Note
+   that the term "agency" is used to identify any party performing the
+   blocking or removal, such as ISPs or private parties, and not just
+   government entities.
+
+   The TakeDownInfo element allows one date element with multiple
+   TakeDownAgency and Comment elements to support operations using
+   multiple agencies.
+
+   +-------------------+
+   | TakeDownInfo      |
+   +-------------------+
+   |                   |<>---(0..1)--[ TakeDownDate ]
+   |                   |<>---(0..*)--[ TakeDownAgency ]
+   |                   |<>---(0..*)--[ TakeDownComments ]
+   +-------------------+
+
+      Figure 5.12.  The TakeDownInfo Element
+
+5.12.1.  TakeDownDate
+
+   Zero or one value of DATETIME.  This is the date and time that
+   takedown of the collector site occurred.
+
+5.12.2.  TakeDownAgency
+
+   Zero or more iodef:MLStringType elements.  This is a free-form string
+   identifying the agency, corporation, or cooperative that performed
+   the takedown.
+
+5.12.3.  TakeDownComments
+
+   Zero or more iodef:MLStringType elements.  A free-form field to add
+   any additional details of this takedown effort or to identify parties
+   that assisted in the effort at an Internet Service Provider (ISP),
+   Computer Emergency Response Team (CERT), or DNS registry.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Cain & Jevans                Standards Track                   [Page 26]
+
+RFC 5901                IODEF Phishing Extensions              July 2010
+
+
+5.13.  ArchivedData Element
+
+   Zero or more values of the ArchivedData element are allowed.
+
+   +-------------------+
+   | ArchivedData      |
+   +-------------------+
+   | ENUM type         |<>---(0..1)--[ URL ]
+   |                   |<>---(0..1)--[ Comments ]
+   |                   |<>---(0..1)--[ Data ]
+   +-------------------+
+
+            Figure 5.13.  The ArchivedData Element
+
+   The ArchivedData URL element is populated with a pointer to the
+   contents of a data collection site, base camp (i.e., development
+   site), or other site used by a phisher.  The ArchivedData Data
+   element may also include a copy of the archived data recovered from a
+   phishing system.  This element will be populated when, for example,
+   an ISP takes down a phisher's website and has copied the site data
+   into an archive file.
+
+   There are four types of archives currently supported, as specified in
+   the type field.
+
+5.13.1.  type Attribute
+
+   REQUIRED.  This parameter specifies the type of site data pointed to
+   by the ArchivedData URL element, from the following list:
+
+   1.  collectionsite.  The archive is a set of files from the
+       collection site.
+
+   2.  basecamp.  The contents of a criminal development site are
+       included in the archive.
+
+   3.  sendersite.  The archive is a set of files or data from a
+       phishing lure sending site.
+
+   4.  credentialInfo.  The included archives are recovered private
+       credentials.
+
+   5.  unspecified.  The archive contents do not fit into one of the
+       above categories and will be described in the DataComments
+       element.
+
+
+
+
+
+
+Cain & Jevans                Standards Track                   [Page 27]
+
+RFC 5901                IODEF Phishing Extensions              July 2010
+
+
+5.13.2.  URL Element
+
+   Zero or one value of anyURL.  As the archive of an entire site can be
+   quite large, the URL element points to an Internet-based server where
+   the actual content of the site archive can be retrieved.  Note that
+   this element just points out where the archive is and does not
+   include the entire archive in the report.  This is the URL where the
+   archive file is located.
+
+5.13.3.  Comments Element
+
+   Zero or one value of iodef:MLStringType.  This field is a free-form
+   area for comments on the archive and/or URL.
+
+5.13.4.  Data Element
+
+   Zero or one value of xs:Base64Binary.  This field contains a base64-
+   encoded version of the data described in the comment field above.
+
+5.14.  RelatedData Element
+
+   Zero or more values of anyURI.  This element allows the listing of
+   other websites or net sites that are related to this incident (e.g.,
+   victim site, etc.).
+
+5.15.  CorrelationData Element
+
+   Zero or more values of iodef:MLStringType.  Any information that
+   correlates this incident to other incidents can be entered here.
+
+5.16.  PRComments Element
+
+   Zero or one value of iodef:MLStringType.  This field allows for any
+   comments specific to this PhraudReport that do not fit in any other
+   field.
+
+5.17.  EmailRecord Element
+
+   This element supports the inclusion of the actual email message
+   received as a phishing lure.  Inclusion of the actual mail message is
+   supported by two methods: either the message may be included as one
+   large string, or the header and body components may be dissected and
+   included as a series of strings.
+
+
+
+
+
+
+
+
+Cain & Jevans                Standards Track                   [Page 28]
+
+RFC 5901                IODEF Phishing Extensions              July 2010
+
+
+   +--------------------+
+   | EmailRecord        |
+   +--------------------+
+   |                    |<>--------------[ EmailCount ]
+   |                    |<>--(0..1)------[ EmailMessage ]
+   |                    |<>--(0..1)------[ EmailComments ]
+   +--------------------+
+
+             Figure 5.14.  The EmailRecord Element
+
+5.17.1.  EmailCount Element
+
+   REQUIRED.  INTEGER.  This field enumerates the number of email
+   messages identified in this record as detected by the reporter.
+
+5.17.2.  EmailMessage Element
+
+   Zero or one value of iodef:MLStringType.  The entire SMTP mail
+   message -- rfc822 header followed by body, as specified in [RFC5322]
+   -- should be inserted as one large text string.  In some communities,
+   this combination is known as the message contents and full headers.
+
+5.17.3.  EmailComments Element
+
+   Zero or one value of iodef:MLStringType elements.  This field
+   contains comments or relevant data not placed elsewhere about the
+   phishing email.
+
+6.  Mandatory IODEF and PhraudReport Elements
+
+   A report about fraud or phishing requires certain identifying
+   information that is contained within the standard IODEF Incident data
+   structure and the PhraudReport extensions.  The following table
+   identifies attributes required to be present in a compliant
+   PhraudReport to report phishing or fraud.  The required attributes
+   are a combination of those required by the base IODEF element, as
+   shown in Figure 6.1, and those required by this document, shown in
+   Figure 6.2.  Attributes identified as required SHALL be populated in
+   conforming phishing activity reports.
+
+
+
+
+
+
+
+
+
+
+
+
+Cain & Jevans                Standards Track                   [Page 29]
+
+RFC 5901                IODEF Phishing Extensions              July 2010
+
+
+   A compliant IODEF PhraudReport SHALL contain the following elements
+   and attributes:
+
+   +--------------+
+   | Incident     |
+   +--------------+
+   | ENUM Purpose |---[ IncidentID ]
+   |              |---[ ReportTime ]
+   |              |---[ Assessment ]
+   |              |   ---> [ Impact ]
+   |              |---[ Contact ]
+   |              |   ---> [ @type ]
+   |              |   ---> [ @role ]
+   |              |   ---> [ * ]
+   |              |---[ EventData ]
+   |              |   ---> [ DetectTime ]
+   |              |   ---> [ AdditionalData ]
+   |              |        ---> [ PhraudReport ]
+   +--------------+
+
+       Figure 6.1.  IODEF Required Classes for a PhraudReport
+
+   +----------------+
+   | PhraudReport   |
+   +----------------+
+   | ENUM FraudType |---[ LureSource ]
+   | STRING Version |   ---> [ iodef:System ]
+   |                |---[ OriginatingSensor ]
+   |                |   --> [ DateFirstSeen ]
+   |                |   --> [ iodef:System ]
+   |                |       --> [ iodef:Node ]
+   |                |
+   +----------------+
+
+           Figure 6.2.  PhraudReport Required Elements
+
+   * Note that the iodef:Contact element is required, but none of its
+   sub-elements are required.  For proper XML correctness, one of the
+   sub-elements is required; pick one.
+
+6.1.  Guidance on Usage
+
+   It may be apparent that the mandatory attributes for a PhraudReport
+   make for a quite sparse report.  As incident forensics and data
+   analysis require detailed information, the originator of a
+   PhraudReport SHOULD include any tidbit of information gleaned from
+   the attack analysis.  Information that is considered sensitive can be
+   marked as such using the restriction parameter of each data element.
+
+
+
+Cain & Jevans                Standards Track                   [Page 30]
+
+RFC 5901                IODEF Phishing Extensions              July 2010
+
+
+   The reporting party is encouraged to provide more than just the
+   minimally required data elements about an event in a PhraudReport.
+   The additional information may be volatile and not recoverable in the
+   future, and may be useful in answering investigation questions or in
+   performing correlation with other reported events.
+
+7.  Security Considerations
+
+   This document specifies a format for encoding a particular class of
+   security incidents appropriate for exchange across organizations.  As
+   merely a data representation, it does not directly introduce security
+   issues.  However, it is guaranteed that parties exchanging instances
+   of this specification will have certain concerns.  For this reason,
+   the underlying message format and transport protocol used MUST ensure
+   the appropriate degree of confidentiality, integrity, and
+   authenticity for the specific environment.
+
+   Organizations that exchange data using this document are URGED to
+   develop operating procedures that document the following areas of
+   concern.
+
+7.1.  Transport-Specific Concerns
+
+   The critical security concerns are that phishing activity reports may
+   be falsified or the PhraudReport may become corrupt during transit.
+   In areas where transmission security or secrecy is questionable, the
+   application of a digital signature and/or message encryption on each
+   report will counteract both of these concerns.  We expect that each
+   exchanging organization will determine the need, and mechanism, for
+   transport protection.
+
+7.2.  Using the iodef:restriction Attribute
+
+   In some instances, data values in particular elements may contain
+   data deemed sensitive by the reporter.  Although there are no
+   general-purpose rules on when to mark certain values as "private" or
+   "need-to-know" via the iodef:restriction attribute, the reporter is
+   cautioned not to apply element-level sensitivity markings unless they
+   believe the receiving party (i.e., the party they are exchanging the
+   event report data with) has a mechanism to adequately safeguard and
+   process the data as marked.  For example, if the PhraudReport element
+   is marked private and contains a phishing collector URL in the
+   DCSite/SiteURL element, can that URL be included within a block list
+   distributed to other parties?  No guidance is provided here except to
+   urge exchanging parties to review the IODEF and PhraudReport
+   documents to decide on common marking rules.
+
+
+
+
+
+Cain & Jevans                Standards Track                   [Page 31]
+
+RFC 5901                IODEF Phishing Extensions              July 2010
+
+
+8.  IANA Considerations
+
+   This document uses URNs to describe XML namespaces and XML schemas
+   conforming to a registry mechanism described in [RFC3688].
+
+   Registration request for the IODEF phishing namespace:
+
+       URI: urn:ietf:params:xml:ns:iodef-phish-1.0
+
+       Registrant Contact: See the "Authors' Addresses" section of this
+       document.
+
+       XML: None.
+
+   Registration request for the IODEF phishing extension XML schema:
+
+       URI: urn:ietf:params:xml:schema:iodef-phish-1.0
+
+       Registrant Contact: See the "Authors' Addresses" section of this
+       document.
+
+       XML: See Appendix A, "Phishing Extensions XML Schema", of this
+       document.
+
+9.  Contributors
+
+   The extensions are an outgrowth of the Anti-Phishing Working Group
+   (APWG) activities in data collection and sharing of phishing and
+   other e-crimeware.  (The APWG has no relationship to an IETF working
+   group.)
+
+   This document has received significant assistance from members of the
+   IETF INCH working group and two groups addressing the phishing
+   problem: members of the APWG and participants in the Financial
+   Services Technology Consortium's Counter-Phishing project.  A special
+   thanks goes to the hardy people who supplied valuable feedback after
+   using this format to report phishing.
+
+10.  References
+
+10.1.  Normative References
+
+   [RFC2119]   Bradner, S., "Key words for use in RFCs to Indicate
+               Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC3275]   Eastlake, D., Reagle, J., and D. Solo, "(Extensible
+               Markup Language) XML-Signature Syntax and Processing",
+               RFC 3275, March 2002.
+
+
+
+Cain & Jevans                Standards Track                   [Page 32]
+
+RFC 5901                IODEF Phishing Extensions              July 2010
+
+
+   [RFC3982]   Newton, A. and M. Sanz, "IRIS: A Domain Registry (dreg)
+               Type for the Internet Registry Information Service
+               (IRIS)", RFC 3982, January 2005.
+
+   [RFC5070]   Danyliw, R., Meijer, J., and Y. Demchenko, "The Incident
+               Object Description Exchange Format", RFC 5070,
+               December 2007.
+
+   [SHA]       National Institute of Standards and Technology, U.S.
+               Department of Commerce, "Secure Hash Standard",
+               FIPS 180-2, August 2002.
+
+10.2.  Informative References
+
+   [KB310516]  Microsoft Corporation, "How to add, modify, or delete
+               registry subkeys and values by using a registration
+               entries (.reg) file", December 2007.
+
+   [RFC3688]   Mealling, M., "The IETF XML Registry", RFC 3688,
+               January 2004.
+
+   [RFC5322]   Resnick, P., "Internet Message Format", RFC 5322,
+               October 2008.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Cain & Jevans                Standards Track                   [Page 33]
+
+RFC 5901                IODEF Phishing Extensions              July 2010
+
+
+Appendix A.  Phishing Extensions XML Schema
+
+<?xml version="1.0" encoding="UTF-8"?>
+<xs:schema attributeFormDefault="unqualified"
+           elementFormDefault="qualified"
+           targetNamespace="urn:ietf:params:xml:ns:iodef-phish-1.0"
+           xmlns="urn:ietf:params:xml:ns:iodef-1.0"
+           xmlns:xs="http://www.w3.org/2001/XMLSchema"
+           xmlns:phish="urn:ietf:params:xml:ns:iodef-phish-1.0"
+           xmlns:iodef="urn:ietf:params:xml:ns:iodef-1.0"
+           xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
+  <xs:import namespace="http://www.w3.org/2000/09/xmldsig#"
+     schemaLocation=
+"http://www.w3.org/TR/2002/REC-xmldsig-core-20020212
+            /xmldsig-core-schema.xsd"/>
+
+  <!--
+  ==========================================================
+  ===  Top-Level Class:  PhraudReport                    ===
+  ==========================================================
+
+  It is incorporated within an
+  IODEF.Incident.EventData.AdditionalData element.
+
+  All the top-level or major elements are defined as xs:types to make
+  future extension easier.
+
+  -->
+
+  <xs:element name="PhraudReport">
+    <xs:complexType>
+      <xs:sequence>
+        <xs:element minOccurs="0" name="PhishNameRef"
+                type="iodef:MLStringType"/>
+        <xs:element minOccurs="0" name="PhishNameLocalRef"
+                type="iodef:MLStringType"/>
+        <xs:element minOccurs="0" name="FraudParameter"
+                    type="iodef:MLStringType"/>
+        <xs:element maxOccurs="unbounded" minOccurs="0"
+                    name="FraudedBrandName" type="iodef:MLStringType"/>
+        <xs:element maxOccurs="unbounded" minOccurs="1"
+                    name="LureSource" type="phish:LureSource.type"/>
+        <xs:element maxOccurs="unbounded" minOccurs="1"
+                    name="OriginatingSensor"
+                    type="phish:OriginatingSensor.type"/>
+        <xs:element maxOccurs="1" minOccurs="0" name="EmailRecord"
+                    type="phish:EmailRecord.type"/>
+
+
+
+
+Cain & Jevans                Standards Track                   [Page 34]
+
+RFC 5901                IODEF Phishing Extensions              July 2010
+
+
+        <xs:element maxOccurs="unbounded" minOccurs="0"
+                    name="DCSite"  type="phish:DCSite.type"/>
+        <xs:element maxOccurs="unbounded" minOccurs="0"
+                    ref="phish:TakeDownInfo"/>
+        <xs:element maxOccurs="unbounded" minOccurs="0"
+                    ref="phish:ArchivedData"/>
+        <xs:element maxOccurs="unbounded" minOccurs="0"
+                    name="RelatedData" type="xs:anyURI"/>
+        <xs:element maxOccurs="unbounded" minOccurs="0"
+                    name="CorrelationData" type="iodef:MLStringType"/>
+        <xs:element maxOccurs="1" minOccurs="0" name="PRComments"
+                    type="iodef:MLStringType"/>
+      </xs:sequence>
+
+      <xs:attribute default="1.0" name="Version" use="optional"/>
+
+      <xs:attribute name="FraudType" type="phish:FraudType.type"
+                    use="required"/>
+
+      <xs:attribute name="ext-value" type="xs:string" use="optional"/>
+    </xs:complexType>
+  </xs:element>
+
+  <xs:simpleType name="FraudType.type">
+    <xs:restriction base="xs:string">
+      <xs:enumeration value="phishing"/>
+      <xs:enumeration value="recruiting"/>
+      <xs:enumeration value="malware distribution"/>
+      <xs:enumeration value="fraudulent site"/>
+      <xs:enumeration value="dnsspoof"/>
+      <xs:enumeration value="archive"/>
+      <xs:enumeration value="other"/>
+      <xs:enumeration value="unknown"/>
+      <xs:enumeration value="ext-value"/>
+    </xs:restriction>
+  </xs:simpleType>
+
+  <!--
+==========================================================
+===           End of the Top-Level Element             ===
+==========================================================
+-->
+
+
+
+
+
+
+
+
+
+Cain & Jevans                Standards Track                   [Page 35]
+
+RFC 5901                IODEF Phishing Extensions              July 2010
+
+
+  <!--
+  ==========================================================
+  ===           The LureSource Element                   ===
+  ==========================================================
+  -->
+
+  <xs:complexType mixed="false" name="LureSource.type">
+    <xs:sequence>
+      <xs:element maxOccurs="unbounded" minOccurs="1"
+              ref="iodef:System"/>
+
+      <xs:element minOccurs="0" maxOccurs="unbounded"
+              ref="phish:DomainData"/>
+
+      <xs:element minOccurs="0" name="IncludedMalware"
+                  type="phish:IncludedMalware.type"/>
+
+      <xs:element minOccurs="0" name="FilesDownloaded">
+        <xs:complexType>
+          <xs:sequence>
+            <xs:element minOccurs="1" name="File"
+                   type="iodef:MLStringType"/>
+          </xs:sequence>
+        </xs:complexType>
+      </xs:element>
+
+      <xs:element minOccurs="0" name="WindowsRegistryKeysModified">
+        <xs:complexType>
+          <xs:sequence>
+            <xs:element maxOccurs="unbounded" name="Key">
+              <xs:complexType>
+                <xs:sequence>
+                  <xs:element name="Name" type="xs:string"/>
+                  <xs:element name="Value" type="xs:string"/>
+                </xs:sequence>
+              </xs:complexType>
+            </xs:element>
+          </xs:sequence>
+        </xs:complexType>
+      </xs:element>
+    </xs:sequence>
+  </xs:complexType>
+
+
+
+
+
+
+
+
+
+Cain & Jevans                Standards Track                   [Page 36]
+
+RFC 5901                IODEF Phishing Extensions              July 2010
+
+
+  <!--
+  ===    LureSource sub-elements    ===
+  -->
+
+  <xs:complexType name="IncludedMalware.type">
+    <xs:sequence>
+      <xs:element name="Name"
+              maxOccurs="unbounded" type="iodef:MLStringType"/>
+      <xs:element minOccurs="0" ref="ds:Reference"/>
+      <xs:element minOccurs="0" name="Data">
+        <xs:complexType >
+            <xs:simpleContent>
+                  <xs:extension base="xs:hexBinary">
+                      <xs:attribute default="55AA55AA55AA55BB"
+                           name="XORPattern" type="xs:hexBinary"/>
+                   </xs:extension>
+            </xs:simpleContent>
+       </xs:complexType>
+      </xs:element>
+    </xs:sequence>
+  </xs:complexType>
+
+  <!--
+ ===========================================================
+ ===  The EmailRecord Element                            ===
+ ===========================================================
+  -->
+
+  <xs:complexType name="EmailRecord.type">
+    <xs:sequence>
+      <xs:element name="EmailCount" type="xs:integer"/>
+      <xs:element maxOccurs="1" minOccurs="0" name="EmailMessage"
+                    type="iodef:MLStringType"/>
+      <xs:element maxOccurs="1" minOccurs="0" name="EmailComments"
+                  type="iodef:MLStringType"/>
+    </xs:sequence>
+  </xs:complexType>
+
+  <!--
+ ===========================================================
+ ===  The Data Collection Site (DCSite) Info Element     ===
+ ===========================================================
+  -->
+
+  <xs:complexType name="DCSite.type">
+    <xs:sequence>
+      <xs:choice>
+        <xs:element name="SiteURL">
+
+
+
+Cain & Jevans                Standards Track                   [Page 37]
+
+RFC 5901                IODEF Phishing Extensions              July 2010
+
+
+          <xs:complexType>
+            <xs:simpleContent>
+              <xs:extension base="iodef:MLStringType">
+                <xs:attribute ref="phish:confidence"/>
+              </xs:extension>
+            </xs:simpleContent>
+          </xs:complexType>
+        </xs:element>
+
+        <xs:element name="Domain">
+          <xs:complexType>
+            <xs:simpleContent>
+              <xs:extension base="iodef:MLStringType">
+                <xs:attribute ref="phish:confidence"/>
+              </xs:extension>
+            </xs:simpleContent>
+          </xs:complexType>
+        </xs:element>
+
+        <xs:element name="EmailSite">
+          <xs:complexType>
+            <xs:simpleContent>
+              <xs:extension base="iodef:MLStringType">
+                <xs:attribute ref="phish:confidence"/>
+              </xs:extension>
+            </xs:simpleContent>
+          </xs:complexType>
+        </xs:element>
+
+        <xs:element name="System">
+         <xs:complexType id="SystemType">
+            <xs:sequence>
+              <xs:element ref="iodef:Address"/>
+            </xs:sequence>
+            <xs:attribute ref="phish:confidence"/>
+         </xs:complexType>
+        </xs:element>
+
+        <xs:element name="Unknown">
+          <xs:complexType>
+            <xs:simpleContent>
+              <xs:extension base="iodef:MLStringType">
+                <xs:attribute  ref="phish:confidence"/>
+              </xs:extension>
+            </xs:simpleContent>
+          </xs:complexType>
+        </xs:element>
+      </xs:choice>
+
+
+
+Cain & Jevans                Standards Track                   [Page 38]
+
+RFC 5901                IODEF Phishing Extensions              July 2010
+
+
+      <xs:element ref="iodef:Node" minOccurs="0" maxOccurs="unbounded"/>
+      <xs:element minOccurs="0" ref="phish:DomainData"/>
+      <xs:element minOccurs="0" ref="iodef:Assessment"/>
+    </xs:sequence>
+
+    <xs:attribute name="DCType" use="required">
+      <xs:simpleType>
+        <xs:restriction base="xs:string">
+          <xs:enumeration value="web"/>
+          <xs:enumeration value="email"/>
+          <xs:enumeration value="keylogger"/>
+          <xs:enumeration value="automation"/>
+          <xs:enumeration value="unspecified"/>
+        </xs:restriction>
+      </xs:simpleType>
+    </xs:attribute>
+  </xs:complexType>
+
+  <!--
+=================================================
+==== The Domain Data Element used in System =====
+=================================================
+-->
+
+  <xs:element name="DomainData">
+    <xs:complexType id="DomainData.type">
+      <xs:sequence>
+        <xs:element maxOccurs="1"
+                  name="Name" type="iodef:MLStringType"/>
+        <xs:element maxOccurs="1" minOccurs="0"
+                  name="DateDomainWasChecked" type="xs:dateTime"/>
+        <xs:element maxOccurs="1" minOccurs="0" name="RegistrationDate"
+                  type="xs:dateTime"/>
+        <xs:element maxOccurs="1" minOccurs="0" name="ExpirationDate"
+                  type="xs:dateTime"/>
+        <xs:element maxOccurs="unbounded" minOccurs="0"
+                 name="Nameservers">
+          <xs:complexType id="Nameservers.type">
+            <xs:sequence>
+              <xs:element name="Server" type="iodef:MLStringType"/>
+              <xs:element ref="iodef:Address" maxOccurs="unbounded"/>
+            </xs:sequence>
+          </xs:complexType>
+        </xs:element>
+        <xs:choice id="DomainContacts" maxOccurs="1" minOccurs="0">
+          <xs:element name="SameDomainContact"
+                     type="iodef:MLStringType"/>
+
+
+
+
+Cain & Jevans                Standards Track                   [Page 39]
+
+RFC 5901                IODEF Phishing Extensions              July 2010
+
+
+          <xs:sequence>
+            <xs:element maxOccurs="unbounded" minOccurs="1"
+                        ref="iodef:Contact"/>
+          </xs:sequence>
+        </xs:choice>
+      </xs:sequence>
+      <xs:attribute name="SystemStatus">
+        <xs:simpleType id="SystemStatus.type">
+          <xs:restriction base="xs:string">
+            <xs:enumeration value="spoofed"/>
+            <xs:enumeration value="fraudulent"/>
+            <xs:enumeration value="innocent-hacked"/>
+            <xs:enumeration value="innocent-hijacked"/>
+            <xs:enumeration value="unknown"/>
+          </xs:restriction>
+        </xs:simpleType>
+      </xs:attribute>
+
+      <xs:attribute name="DomainStatus">
+        <xs:simpleType id="DomainStatus.type">
+          <xs:restriction base="xs:string">
+            <xs:enumeration value="reservedDelegation"/>
+            <xs:enumeration value="assignedAndActive"/>
+            <xs:enumeration value="assignedAndInactive"/>
+            <xs:enumeration value="assignedAndOnHold"/>
+            <xs:enumeration value="revoked"/>
+            <xs:enumeration value="transferPending"/>
+            <xs:enumeration value="registryLock"/>
+            <xs:enumeration value="registrarLock"/>
+            <xs:enumeration value="other"/>
+            <xs:enumeration value="unknown"/>
+          </xs:restriction>
+        </xs:simpleType>
+      </xs:attribute>
+    </xs:complexType>
+  </xs:element>
+
+  <xs:element name="Confidence">
+    <xs:simpleType>
+      <xs:restriction base="xs:nonNegativeInteger">
+          <xs:minInclusive value="0"/>
+          <xs:maxInclusive value="100"/>
+       </xs:restriction>
+     </xs:simpleType>
+  </xs:element>
+
+
+
+
+
+
+Cain & Jevans                Standards Track                   [Page 40]
+
+RFC 5901                IODEF Phishing Extensions              July 2010
+
+
+<xs:attribute name="confidence">
+  <xs:simpleType>
+    <xs:restriction base="xs:nonNegativeInteger">
+      <xs:minInclusive value="0"/>
+      <xs:maxInclusive value="100"/>
+    </xs:restriction>
+  </xs:simpleType>
+</xs:attribute>
+
+  <!--
+=====================================================================
+= ext-role Values for use within the DomainContact Contacts Element =
+=====================================================================
+-->
+
+  <xs:simpleType name="ext-role">
+    <xs:restriction base="xs:string">
+      <xs:enumeration value="billingContacts"/>
+      <xs:enumeration value="technicalContacts"/>
+      <xs:enumeration value="administrativeContacts"/>
+      <xs:enumeration value="legalContacts"/>
+      <xs:enumeration value="zoneContacts"/>
+      <xs:enumeration value="abuseContacts"/>
+      <xs:enumeration value="securityContacts"/>
+      <xs:enumeration value="otherContacts"/>
+      <xs:enumeration value="hostingProvider"/>
+    </xs:restriction>
+  </xs:simpleType>
+
+  <!--
+=================================================
+===  The OriginatingSensor Data Element       ===
+=================================================
+-->
+
+  <xs:complexType name="OriginatingSensor.type">
+    <xs:sequence>
+      <xs:element name="DateFirstSeen" type="xs:dateTime"/>
+      <xs:element maxOccurs="unbounded" minOccurs="1"
+                ref="iodef:System"/>
+    </xs:sequence>
+
+    <xs:attribute name="OriginatingSensorType" use="required">
+      <xs:simpleType id="OriginatingSensorType.type">
+        <xs:restriction base="xs:NMTOKENS">
+          <xs:enumeration value="web"/>
+          <xs:enumeration value="webgateway"/>
+          <xs:enumeration value="mailgateway"/>
+
+
+
+Cain & Jevans                Standards Track                   [Page 41]
+
+RFC 5901                IODEF Phishing Extensions              July 2010
+
+
+          <xs:enumeration value="browser"/>
+          <xs:enumeration value="ispsensor"/>
+          <xs:enumeration value="human"/>
+          <xs:enumeration value="honeypot"/>
+          <xs:enumeration value="other"/>
+        </xs:restriction>
+      </xs:simpleType>
+    </xs:attribute>
+  </xs:complexType>
+
+  <!--
+======================================================
+===            The TakeDown Data Structure         ===
+======================================================
+-->
+
+  <xs:element name="TakeDownInfo" type="phish:TakeDownInfo.type"/>
+
+  <xs:complexType name="TakeDownInfo.type">
+    <xs:sequence>
+      <xs:element maxOccurs="1" minOccurs="0" name="TakeDownDate"
+                  type="xs:dateTime"/>
+
+      <xs:element maxOccurs="unbounded" minOccurs="0"
+              name="TakeDownAgency"  type="iodef:MLStringType"/>
+
+      <xs:element maxOccurs="unbounded" minOccurs="0"
+              name="TakeDownComments"  type="iodef:MLStringType"/>
+    </xs:sequence>
+  </xs:complexType>
+
+  <!--
+=========================================================
+===         The ArchivedData Element                  ===
+=========================================================
+-->
+  <xs:element name="ArchivedData" type="phish:ArchivedData.type"/>
+
+  <xs:complexType name="ArchivedData.type">
+    <xs:sequence>
+      <xs:element minOccurs="0" name="URL" type="xs:anyURI"/>
+      <xs:element minOccurs="0" name="Comments"
+              type="iodef:MLStringType"/>
+      <xs:element maxOccurs="1" minOccurs="0" name="Data"
+                  type="xs:base64Binary"/>
+    </xs:sequence>
+
+
+
+
+
+Cain & Jevans                Standards Track                   [Page 42]
+
+RFC 5901                IODEF Phishing Extensions              July 2010
+
+
+    <xs:attribute name="type" use="required">
+      <xs:simpleType id="ArchivedDataType.type">
+        <xs:restriction base="xs:NMTOKENS">
+          <xs:enumeration value="collectionsite"/>
+          <xs:enumeration value="basecamp"/>
+          <xs:enumeration value="sendersite"/>
+          <xs:enumeration value="credentialInfo"/>
+          <xs:enumeration value="unspecified"/>
+        </xs:restriction>
+      </xs:simpleType>
+    </xs:attribute>
+  </xs:complexType>
+
+</xs:schema>
+
+Appendix B.  Example Virus Report
+
+   This section shows a received electronic mail message that included a
+   virus in a zipped attachment and a report that was generated for that
+   message.
+
+B.1.  Received Email
+
+ From: support@example.com
+ Sent: Friday, June 10, 2005 3:52 PM
+ To: someone@example.com
+ Subject: Account update
+
+ To:          someone@example.com
+ Date:      Sun, 10 June 2005 3:52:44 +0200
+
+
+ We would like to inform you that we have released a new version of our
+ Customer Form.  This form is required to be completed by all customers.
+
+ Please follow these steps:
+
+ 1.Open the form at http://www.example.com/customerservice/cform.php
+ <http://www.2.example.com/customerservice/cform.php
+         &amp;email=(someone@example.com)> .
+ 2.Follow given instructions.
+
+ Thank you,
+ Our Support Team
+
+
+
+
+
+
+
+Cain & Jevans                Standards Track                   [Page 43]
+
+RFC 5901                IODEF Phishing Extensions              July 2010
+
+
+B.2.  Generated Report
+
+   NOTE: Some wrapping and folding liberties have been applied to fit it
+   into the margins.
+
+ <?xml version="1.0" encoding="UTF-8"?>
+ <IODEF-Document lang="en-US"
+   xmlns:phish="urn:ietf:params:xml:ns:iodef-phish-1.0"
+   xmlns="urn:ietf:params:xml:ns:iodef-1.0"
+   xmlns:iodef="urn:ietf:params:xml:ns:iodef-1.0">
+ <Incident purpose="reporting" ext-purpose="create">
+   <IncidentID name="example.com">PAT2005-06</IncidentID>
+   <ReportTime>2005-06-22T08:30:00-05:00</ReportTime>
+   <Description>This is a test report from actual data.
+    </Description>
+   <Assessment>
+     <Impact type="social-engineering"/>
+     <Confidence rating="high"/>
+   </Assessment>
+   <Contact role="creator" type="person">
+     <ContactName>patcain</ContactName>
+     <Email>pcain@coopercain.com</Email>
+   </Contact>
+   <EventData>
+     <DetectTime>2005-06-21T18:22:02-05:00</DetectTime>
+     <AdditionalData dtype="xml">
+     <phish:PhraudReport FraudType="phishing">
+       <phish:FraudParameter>
+        Subject: Account Update
+       </phish:FraudParameter>
+       <phish:FraudedBrandName>Cooper-Cain
+       </phish:FraudedBrandName>
+       <phish:LureSource>
+         <System category="source">
+           <Node>
+            <Address>192.0.2.18</Address>
+           </Node>
+         </System>
+         <phish:IncludedMalware>
+           <phish:Name>W32.Mytob.EA@mm</phish:Name>
+         </phish:IncludedMalware>
+       </phish:LureSource>
+       <phish:OriginatingSensor OriginatingSensorType="human">
+         <phish:DateFirstSeen>2005-06-10T15:52:11-05:00
+         </phish:DateFirstSeen>
+         <System>
+           <Node>
+             <Address>192.0.2.13</Address>
+
+
+
+Cain & Jevans                Standards Track                   [Page 44]
+
+RFC 5901                IODEF Phishing Extensions              July 2010
+
+
+           </Node>
+         </System>
+       </phish:OriginatingSensor>
+       <phish:EmailRecord>
+         <phish:EmailCount>1</phish:EmailCount>
+         <phish:EmailMessage>
+ Return-path: &lt;support@example.com&gt;
+  Envelope-to: someone@example.com
+ Delivery-date: Fri, 10 Jun 2005:52:11-0400
+ Received: from dsl18-2-0-192.dsl.example.net([192.0.2.18]
+  helo=example.com) by mail06.example.com esmtp (Exim) id
+  1DgpXy-0002Ua-IR for someone@example.com;,
+  10 Jun 2005 15:52:10-0400
+ From: support@example.com
+ To: someone@example.com
+ Subject: Account Update
+ Date: Fri, 10 Jun 2005 12:52:00 -0700
+ MIME-Version: 1.0
+ Content Type: text/plain;
+         charset="Windows-1251"
+ X-Priority: 3MSMail-Priority: Normal
+ X-EN-OrigIP: 192.0.2.18
+ EN-OrigHost: dsl18-2-0-192.dsl.example.net
+ Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16)
+  on.example.net
+ X-Spam-Level: ***** X-Spam-Status: No,
+  score=5.6 required=6.0 tests=BAYES_95,CABLEDSL,HTML_20_30,
+  HTML_MESSAGE,MIME_HTML_ONLY,MISSING_MIMEOLE,
+  NO_REAL_NAME,
+  PRIORITY_NO_NAME autolearn=disabled version=3.0.2
+
+ From:support@example.com
+ Sent: Friday, June 10, 2005 3:52 PM
+ Subject: Account update
+
+ To:          someone@example.com
+ Date:      Sun, 10 June 2005 3:52:44 +0200
+
+
+ We would like to inform you that we have released a new version of our
+ Customer Form.  This form is required to be completed by all customers.
+
+ Please follow these steps:
+
+ 1.Open the form at http://www.example.com/customerservice/cform.php
+ &lt;http://www.2.example.com/customerservice/cform.php
+         &amp;email=(someone@example.com)> .
+ 2.Follow given instructions.
+
+
+
+Cain & Jevans                Standards Track                   [Page 45]
+
+RFC 5901                IODEF Phishing Extensions              July 2010
+
+
+ Thank you,
+ Our Support Team
+            </phish:EmailMessage>
+         </phish:EmailRecord>
+       </phish:PhraudReport>
+     </AdditionalData>
+     </EventData>
+   </Incident>
+ </IODEF-Document>
+
+Appendix C.  Sample Phishing Report
+
+   A sample report generated from a received electronic mail phishing
+   message in shown in this section.
+
+C.1.  Received Lure
+
+   Return-path: <service@example.com>
+   Envelope-to: pcain@example.com
+   Delivery-date: Tue, 13 Jun 2006 05:37:22 -0400
+   Received: from mail15.example.com ([10.1.1.161]
+    helo=mail15.example.com)
+    by mailscan38.example.com with esmtp (Exim)
+    id 1Fq5Kr-0005wU-LT for pcain@example.com; Tue, 13 Jun 2006
+    05:37:21 -0400
+   Received: from [192.0.2.61] (helo=TSI)
+   by mail15.example.com with
+    esmtp (Exim) id 1Fq5Bj-0006dv-6b
+   for pcain@example.com; Tue, 13 Jun 2006 05:37:21 -0400
+   Received: from User ([192.0.2.157]) by TSI with
+    Microsoft SMTPSVC(5.0.2195.6713);
+   Tue, 13 Jun 2006 02:24:30 -0400
+   Reply-To: <nospam@example.org>
+   From: "company"<service@example.com>
+   Subject: * * * Update & Verify Your Example Company Account * * *
+   Date: Tue, 13 Jun 2006 02:36:34 -0400
+   MIME-Version: 1.0
+   Content-Type: text/html; charset="Windows-1251"
+   Content-Transfer-Encoding: 7bit
+   X-Priority: 1
+   X-MSMail-Priority: High
+   X-Mailer: Microsoft Outlook Express 6.00.2600.0000
+   X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
+   Bcc:
+   Message-ID: <TSIlYbvhBISmT6QcWY90000085f@TSI>
+   X-OriginalArrivalTime: 13 Jun 2006 06:24:30.0218 (UTC)
+   FILETIME=[072A66A0:01C68EB2]
+   X-EN-OrigSender: service@example.com
+
+
+
+Cain & Jevans                Standards Track                   [Page 46]
+
+RFC 5901                IODEF Phishing Extensions              July 2010
+
+
+   X-EN-OrigIP: 192.0.2.1
+   X-EN-OrigHost: unknown
+
+   Company<http://www.example.com/images/company_logo.gif>
+    <http://www.example.com/images/pixel.gif>
+    <http://www.example.com/images/pixel.gif>
+    <http://www.example.com/images/pixel.gif>
+   Account Update Request
+
+   Dear Example. member:,
+
+   You are receiving this notification because company is required by
+   law to notify you, that you urgently need to update your online
+   account statement, due to high risks of fraud intentions.
+
+   The updating of your example account can be done at any time by
+   clicking on the link shown below
+   http://www.example.com/cgi-bin/webscr?cmd=_login-run
+   <http://192.0.2.41:8080/.cgi-bin/.webscr/.secure-
+   login/%20/%20/.payp
+   al.com/index.htm>
+
+   Once you log in, update your account information.
+   After updating your account, click on the History sub tab of your
+   Account Overview page to see your most recent statement.
+
+   If you need help with your password, click the Help link that is at
+   the upper righthand side of the company website.  To report errors
+   in your statement or make inquiries, click the Contact Us link in the
+   footer on any page of the company website, call our Customer Service
+   center at (999) 555-0167, or write us at:
+
+   Company, Inc.
+   P.O. Box 0
+   Anytown, MA 00000
+
+   Sincerely,
+
+   Big Example Company
+
+    <http://www.example.com/images/dot_row_long.gif>
+
+
+
+
+
+
+
+
+
+
+Cain & Jevans                Standards Track                   [Page 47]
+
+RFC 5901                IODEF Phishing Extensions              July 2010
+
+
+C.2.  Phishing Report
+
+  <?xml version="1.0" encoding="UTF-8"?>
+  <IODEF-Document xmlns:phish="urn:ietf:params:xml:ns:iodef-phish-1.0"
+      xmlns="urn:ietf:params:xml:ns:iodef-1.0"
+      xmlns:iodef="urn:ietf:params:xml:ns:iodef-1.0" lang="en-US">
+   <Incident purpose="mitigation" ext-purpose="create"
+    restriction="private">
+    <IncidentID name="example.com">CC200600000002</IncidentID>
+    <ReportTime>2006-06-13T21:14:56-05:00</ReportTime>
+    <Description>This is a sample phishing email received report.
+          The phish was actually received as is.</Description>
+    <Assessment>
+     <Impact severity="high" type="social-engineering"/>
+     <Confidence rating="numeric">85</Confidence>
+    </Assessment>
+    <Contact role="creator" type="person">
+     <ContactName>patcain</ContactName>
+     <Email>pcain@example.com</Email>
+    </Contact>
+    <EventData>
+     <DetectTime>2006-06-13T05:37:21-04:00</DetectTime>
+     <AdditionalData dtype="xml">
+      <phish:PhraudReport FraudType="phishing">
+       <phish:FraudParameter>
+         * * * Update &amp; Verify Your Company Account * * *
+       </phish:FraudParameter>
+       <phish:FraudedBrandName>company</phish:FraudedBrandName>
+       <phish:LureSource>
+        <System category="source">
+         <Node>
+          <Address>192.0.2.4</Address>
+         </Node>
+        </System>
+       </phish:LureSource>
+       <phish:OriginatingSensor OriginatingSensorType="mailgateway">
+       <phish:DateFirstSeen>
+               2006-06-13T05:37:22-04:00</phish:DateFirstSeen>
+        <System>
+         <Node>
+          <NodeRole category="mail"/>
+         </Node>
+        </System>
+       </phish:OriginatingSensor>
+
+
+
+
+
+
+
+Cain & Jevans                Standards Track                   [Page 48]
+
+RFC 5901                IODEF Phishing Extensions              July 2010
+
+
+       <phish:EmailRecord>
+        <phish:EmailCount>1</phish:EmailCount>
+        <phish:EmailMessage>
+  Return-path: &lt;service@example.com>
+  Envelope-to: pcain@example.com
+  Delivery-date: Tue, 13 Jun 2006 05:37:22 -0400
+  Received: from mail15.example.com ([10.1.1.161]
+   helo=mail15.example.com)
+   by mailscan38.example.com with esmtp (Exim)
+   id 1Fq5Kr-0005wU-LT for pcain@example.com; Tue, 13 Jun 2006
+   05:37:21 -0400
+  Received: from [192.0.2.61] (helo=TSI)
+  by mail15.example.com with
+   esmtp (Exim) id 1Fq5Bj-0006dv-6b
+  for pcain@example.com; Tue, 13 Jun 2006 05:37:21 -0400
+  Received: from User ([192.0.2.157]) by TSI with
+   Microsoft SMTPSVC(5.0.2195.6713);
+  Tue, 13 Jun 2006 02:24:30 -0400
+  Reply-To: &lt;nospam@example.org>
+  From: "company"&lt;service@example.com>
+  Subject: * * * Update &amp; Verify Your Example Company Account * * *
+  Date: Tue, 13 Jun 2006 02:36:34 -0400
+  MIME-Version: 1.0
+  Content-Type: text/html; charset="Windows-1251"
+  Content-Transfer-Encoding: 7bit
+  X-Priority: 1
+  X-MSMail-Priority: High
+  X-Mailer: Microsoft Outlook Express 6.00.2600.0000
+  X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
+  Bcc:
+  Message-ID: &lt;TSIlYbvhBISmT6QcWY90000085f@TSI>
+  X-OriginalArrivalTime: 13 Jun 2006 06:24:30.0218 (UTC)
+  FILETIME=[072A66A0:01C68EB2]
+  X-EN-OrigSender: service@example.com
+  X-EN-OrigIP: 192.0.2.1
+  X-EN-OrigHost: unknown
+
+  &lt;img src="http://www.example.com/images/company_logo.gif"&gt;
+  &lt;img src="http://www.example.com/images/pixel.gif"&gt;
+  &lt;img src="http://www.example.com/images/pixel.gif"&gt;
+  &lt;img src="http://www.example.com/im/pixel.gif"&gt;
+  Account Update Request
+
+  Dear Example. member:,
+  You are receiving this notification because company is required by
+  law to notify you, that you urgently need to update your online
+  account statement, due to high risks of fraud intentions.
+
+
+
+
+Cain & Jevans                Standards Track                   [Page 49]
+
+RFC 5901                IODEF Phishing Extensions              July 2010
+
+
+  The updating of your example account can be done at any time by
+  clicking on the link shown below
+  &lt;a href="http://192.0.2.41:8080/.cgi-bin/.webscr/.secure-
+  login/%20/%20/.example.com/index.htm">
+  http://www.example.com/cgi-bin/webscr?cmd=_login-run &lt;/a>
+
+  Once you log in,update your account information.
+  After updating your account click on the History sub tab of your
+  Account Overview page to see your most recent statement.
+
+  If you need help with your password, click the Help link which is at
+  the upper right hand side of the company website.  To report errors in
+  your statement or make inquiries, click the Contact Us link in the
+  footer on any page of the company website, call our Customer Service
+  center at (999) 555-0167, or write us at:
+
+  Company, Inc.
+  P.O. Box 0
+  Anytown, MA 00000
+
+  Sincerely,
+
+  Big Example Company
+
+   &lt;img src="http://www.example.com/images/dot_row_long.gif">
+  </phish:EmailMessage>
+       </phish:EmailRecord>
+       <phish:DCSite DCType="web">
+        <phish:SiteURL>http://190.0.2.41:8080/.cgi-bin/.webscr/.secure-
+           login/%20%20/.example.com/index.htm</phish:SiteURL>
+        <phish:DomainData DomainStatus="assignedAndActive"
+          SystemStatus="unknown">
+         <phish:Name>bad.example.com</phish:Name>
+         <phish:DateDomainWasChecked>2006-06-14T13:05:00-05:00
+         </phish:DateDomainWasChecked>
+         <phish:RegistrationDate>
+                   2000-12-13T00:00:00</phish:RegistrationDate>
+         <phish:Nameservers>
+          <phish:Server>ns1.example.net</phish:Server>
+          <Address>192.0.2.18</Address>
+         </phish:Nameservers>
+        </phish:DomainData>
+       </phish:DCSite>
+      </phish:PhraudReport>
+     </AdditionalData>
+    </EventData>
+   </Incident>
+  </IODEF-Document>
+
+
+
+Cain & Jevans                Standards Track                   [Page 50]
+
+RFC 5901                IODEF Phishing Extensions              July 2010
+
+
+Authors' Addresses
+
+   Patrick Cain
+   The Cooper-Cain Group, Inc.
+   P.O. Box 400992
+   Cambridge, MA 02140
+   USA
+
+   EMail: pcain@coopercain.com
+
+
+   David Jevans
+   The Anti-Phishing Working Group
+   5150 El Camino Real, Suite A20
+   Los Altos, CA 94022
+   USA
+
+   EMail: dave.jevans@antiphishing.org
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Cain & Jevans                Standards Track                   [Page 51]
+