[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 07 RFC 5901

Network Working Group                                            P. Cain
Internet-Draft                               The Cooper-Cain Group, Inc.
Intended status: Standards Track                               D. Jevans
Expires: April 26, 2008                  The Anti-Phishing Working Group
                                                        October 24, 2007


 Extensions to the IODEF-Document Class for Phishing, Fraud, and Other
                               Crimeware
                 draft-cain-post-inch-phishingextns-03

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on April 26, 2008.

Copyright Notice

   Copyright (C) The IETF Trust (2007).












Cain & Jevans            Expires April 26, 2008                 [Page 1]

Internet-Draft          IODEF Phishing Extensions           October 2007


Abstract

   This document extends the Incident Object Description Exchange Format
   (IODEF) to support the reporting of phishing, fraud, other types of
   electronic crime, and widespread spam incidents.  These extensions
   are flexible enough to support information gleaned from activities
   throughout the entire electronic fraud cycle.  Both simple reporting
   and complete forensic reports are possible, as is consolidated
   reporting of multiple phishing incidents.

   The extensions defined in this document are used to generate two
   different types of reports: a fraud and phishing report and a wide-
   spread spam report.  Although similar in structure, each report has
   different required objects and intents.





































Cain & Jevans            Expires April 26, 2008                 [Page 2]

Internet-Draft          IODEF Phishing Extensions           October 2007


RFC 2129 Keywords

   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].


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  5
     1.1.  Why a Common Report Format is Needed . . . . . . . . . . .  5
     1.2.  Relation to the INCH IODEF Data Model  . . . . . . . . . .  6
   2.  The Elements of Phishing/Fraud Activity  . . . . . . . . . . .  7
   3.  Fraud Activity Reporting via IODEF-Documents . . . . . . . . .  8
     3.1.  Fraud Report Types . . . . . . . . . . . . . . . . . . . .  8
     3.2.  Fraud Report XML Representation  . . . . . . . . . . . . .  8
     3.3.  Correctness of Fraud Activity Reports  . . . . . . . . . .  9
   4.  PhraudReport Element Definitions . . . . . . . . . . . . . . . 10
     4.1.  PhraudReport Structure . . . . . . . . . . . . . . . . . . 10
     4.2.  Reuse of IODEF-defined Elements  . . . . . . . . . . . . . 11
     4.3.  Element and Attribute Specification Format . . . . . . . . 11
     4.4.  Version attribute  . . . . . . . . . . . . . . . . . . . . 11
     4.5.  FraudType attribute  . . . . . . . . . . . . . . . . . . . 12
     4.6.  PhishNameRef element . . . . . . . . . . . . . . . . . . . 13
     4.7.  PhishNameLocalRef element  . . . . . . . . . . . . . . . . 13
     4.8.  FraudedBrandName element . . . . . . . . . . . . . . . . . 13
     4.9.  LureSource element . . . . . . . . . . . . . . . . . . . . 13
     4.10. OriginatingSensor Element  . . . . . . . . . . . . . . . . 21
     4.11. The DCSite element . . . . . . . . . . . . . . . . . . . . 23
     4.12. TakeDownInfo element . . . . . . . . . . . . . . . . . . . 25
     4.13. ArchivedData element . . . . . . . . . . . . . . . . . . . 25
     4.14. RelatedData element  . . . . . . . . . . . . . . . . . . . 27
     4.15. CorrelationData element  . . . . . . . . . . . . . . . . . 27
     4.16. PRComments element . . . . . . . . . . . . . . . . . . . . 27
     4.17. EmailRecord element  . . . . . . . . . . . . . . . . . . . 27
   5.  IODEF Required Elements  . . . . . . . . . . . . . . . . . . . 30
     5.1.  Fraud or Phishing Report . . . . . . . . . . . . . . . . . 30
     5.2.  Wide-Spread Spam Report  . . . . . . . . . . . . . . . . . 31
     5.3.  Guidance on Usage  . . . . . . . . . . . . . . . . . . . . 31
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 33
     6.1.  Transport-specific concerns  . . . . . . . . . . . . . . . 33
     6.2.  Using the iodef:restriction attribute  . . . . . . . . . . 33
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 34
   8.  Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 35
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 36
     9.1.  Normative References . . . . . . . . . . . . . . . . . . . 36
     9.2.  Informative References . . . . . . . . . . . . . . . . . . 36
   Appendix A.  Appendix A. Phishing Extensions XML Schema  . . . . . 37



Cain & Jevans            Expires April 26, 2008                 [Page 3]

Internet-Draft          IODEF Phishing Extensions           October 2007


   Appendix B.  Example Virus Report  . . . . . . . . . . . . . . . . 48
     B.1.  Received Email . . . . . . . . . . . . . . . . . . . . . . 48
     B.2.  Generated Report . . . . . . . . . . . . . . . . . . . . . 48
   Appendix C.  Sample Phishing Report  . . . . . . . . . . . . . . . 51
     C.1.  Received Lure  . . . . . . . . . . . . . . . . . . . . . . 51
     C.2.  Phishing Report  . . . . . . . . . . . . . . . . . . . . . 52
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 56
   Intellectual Property and Copyright Statements . . . . . . . . . . 57











































Cain & Jevans            Expires April 26, 2008                 [Page 4]

Internet-Draft          IODEF Phishing Extensions           October 2007


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 a 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) [RFC-IODEF] that can be used to
   describe information about a phishing incident or wide-spread spam
   incident.  Sections 2 and 3 of this document introduce the high-level
   report format and how to use it.  Sections 4 and 5 describe the data
   elements of the fraud extensions.  This document includes an XML
   schema for the extensions and a few example fraud reports.

1.1.  Why a Common Report Format is Needed

   The rise in phishing and fraud activities via e-mail, instant
   message, DNS corruption, and malicious code insertion has driven
   corporations, Internet Service Providers, consumer agencies, and
   financial institutions to begin to collect and correlate phishing
   attack information.  The collected data allows them to better
   coordinate mitigation activities and support in the pursuit and
   prosecution of the attacker.

   By using a common format, it becomes easier for an organization to
   engage in this coordination as well as correlation of information
   from multiple sources or products into a cohesive view.  As the
   number of data sources increases the usefulness of a common format
   increases as it decreases the need for multiple tools to interpret
   every different type of report.

   The accumulation and correlation of information is also important in
   resolving phishing incidents detected externally as the phished
   organization may not even be aware of the attack.  Third parties
   aware of the attack may wish to notify the phished organization or a
   central notification service so adequate responses could commence.
   The targeted organization's internal monitoring systems may also
   detect the attack and wish to take mitigation steps.



Cain & Jevans            Expires April 26, 2008                 [Page 5]

Internet-Draft          IODEF Phishing Extensions           October 2007


   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.2.  Relation to the INCH IODEF Data Model

   Instead of defining a new report format, this draft defines an
   extension to [RFC-IODEF].  The IODEF defines a flexible and
   extensible format and supports a granular level of specificity.  This
   phishing extension reuses subsets of the IODEF data model and, where
   appropriate, specifies 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.

1.2.1.  Fraudulent Activity Extensions to the IODEF-Document

   Fraudulent 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 into 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 and
   Record Item 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 [RFC-IODEF].









Cain & Jevans            Expires April 26, 2008                 [Page 6]

Internet-Draft          IODEF Phishing Extensions           October 2007


2.  The Elements of Phishing/Fraud Activity

   +-----------+        +------------------+
   | Fraudster |<---<-- | Collection Point |<---O--<----<----+
   +----+------+        +------------------+    |            |
        |                                       |            |
        |                                    +--|-----+      ^
        |                                    | Sensor | Credentials
        |                                    +-|------+      |
        |      +---------------+               |        +-------+
        \--->--| Attack Source |--Phish-->-----O------> | User/ |
               +---------------+                        |Victim |
                                                        +-------+

            Figure 2.1: The Components of Internet Phishing


   Internet-based Phishing and Fraud activities are normally comprised
   of at least four 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 User, Victim, or intended target of the fraud/phish.

      4.  The collection point, where the victim sends their credentials
      or personal data if they have been duped by the phisher.

   If we take a holistic view of the attack, there are some additional
   components:

      5.  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.

      6.  A forensic or archive site where an investigator has copied or
      otherwise retained the data used for the fraud attempt or
      credential collection.










Cain & Jevans            Expires April 26, 2008                 [Page 7]

Internet-Draft          IODEF Phishing Extensions           October 2007


3.  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 sections, reporting Fraud Activity has
   three primary components: choosing a report type; a format for the
   data; and how to check correctness of the format.

3.1.  Fraud Report Types

   There are three types of reports relating to 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 take down information, or related
   activities.  Lastly, a reporter may have realized that the report is
   in error or contain significant incorrect data and the prudent
   reaction is to *delete* the report.

   The three types of reports are denoted through the use of the ext-
   pupose attribute of an Incident element.  A new report contains an
   empty or a "create" ext-purpose value; an updated report contains a
   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 lifecycle is very environment specific.

3.2.  Fraud Report XML Representation

   The IODEF Incident element [IODEF, 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 representations is for illustrative purposes
   only; elements are specified in XML as defined by A















Cain & Jevans            Expires April 26, 2008                 [Page 8]

Internet-Draft          IODEF Phishing Extensions           October 2007


   +--------------------+
   | 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 3.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
   iodef:AdditionalData element of iodef:EventData.  The PhraudReport
   element is added to the IODEF using its defined extension procedure
   documented in Section 5 of [RFC-IODEF].

   One IODEF-Document may contain information on multiple incidents with
   information for each incident contained within an iodef:Incident
   element [IODEF, Section 3.12].

3.3.  Correctness of Fraud Activity Reports

   The Fraud Activity Report MUST pass XML validation using the schema
   defined in [RFC-IODEF] and the extensions defined in

   <AppendixA> of this document.











Cain & Jevans            Expires April 26, 2008                 [Page 9]

Internet-Draft          IODEF Phishing Extensions           October 2007


4.  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 2.  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.

4.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 ]
   |                  |<>--{0..1}--[ FraudParameter ]
   |                  |<>--{0..*}--[ FraudedBrandName ]
   |                  |<>--{1..*}--[ LureSource ]
   |                  |<>--{1..*}--[ OriginatingSensor ]
   |                  |<>--{0..1}--[ EmailRecord ]
   |                  |<>--{0..*}--[ DCSite ]
   |                  |<>--{0..*}--[ TakeDownInfo ]
   |                  |<>--{0..*}--[ ArchivedData ]
   |                  |<>--{0..*}--[ RelatedData ]
   |                  |<>--{0..*}--[ CorrelatedData ]
   |                  |<>--{0..1}--[ PRComments ]
   +------------------+

           Figure 4.1: The PhraudReport Element


   Relevant information about a phishing or fraud event can be encoded
   by encoding the 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            Expires April 26, 2008                [Page 10]

Internet-Draft          IODEF Phishing Extensions           October 2007


   c.  The DCSite describes the technical details of the credential
       collection point.

   d.  The Originating Sensor 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.

4.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.

   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 [RFC-IODEF].  Each element in a
   PhraudReport is used as described in the following sections.

4.3.  Element and Attribute Specification Format

   The following sections describe the components of a PhraudReport XML
   element.  Each description is structured as follows.

      1.  Terse XML-type identifier for the element.

      2.  Indication of whether this item is REQUIRED or optional.

      3.  Description of the element and its intended use.

   Elements that contain sub-elements or enumerated values are further
   sub-sectioned.

   The rest of this section describes elements of the PhraudReport.

4.4.  Version attribute

   STRING.  The version shall be the value 0.01 to be compliant with
   this document.  [This value will be changed to "1.0" when this
   document progresses.]





Cain & Jevans            Expires April 26, 2008                [Page 11]

Internet-Draft          IODEF Phishing Extensions           October 2007


4.5.  FraudType attribute

   One ENUM.  The FraudType attribute describes the type of fraudulent
   activity described in this PhraudReport and contains one of the
   following values:

   1.   phishemail.  The FraudParameter should be the email subject line
        of the phishing email.  This type is a standard email phish,
        usually sent as spam, and is intended to derive financial loss
        to the recipient.

   2.   recruitemail.  The FraudParameter is the email subject line of
        the phishing email.  This type of email phish does not pose a
        potential financial loss to the recipient, but covers other
        cases of the phish and fraud lifecycle.

   3.   malwareemail.  The FraudParameter is the email subject line of
        the phishing email.  This type of email phish does not pose a
        potential financial loss to the recipient, but lures the
        recipient to an infected site.

   4.   fraudsite.  This identifies a known fraudulent site that does
        not necessarily send spam but is used for lures.  The
        FraudParameter may be used to identify the website.

   5.   dnsspoof.  This choice does not have a related FraudParameter.
        This is used for a spoofed DNS (e.g., malware changes localhost
        file so visits to www.example.com go to another IP address
        chosen by the fraudster).

   6.   keylogger.  This choice does not have a FraudParameter and
        specifies a keylogger downloaded with the lure.

   7.   ole.  There is no FraudParameter.  This identifies background
        Microsoft Object Linking and Embedding (OLE) information that
        comes as part of a lure.

   8.   im.  The FraudParameter should be the malicious instant message
        (IM) link supplied to the user.

   9.   cve.  This choice identifies CVE-known malware, with the Common
        Vulnerability and Exposures project (CVE) number as the
        FraudParameter.

   10.  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 ArchiveInfo element.



Cain & Jevans            Expires April 26, 2008                [Page 12]

Internet-Draft          IODEF Phishing Extensions           October 2007


   11.  spamreport.  This type is used when the PhraudReport is
        reporting a large-scale spam activity.  The FraudParameter
        should be the spam email subject line.

   12.  voip.  The lure was received via a voice-over-IP connection
        identified by the information in the FraudParameter field.

   13.  other.  This is used to identify not-yet-enumerated fraud types.

   14.  unknown.  This choice may have an associated FraudParameter.  It
        is used to cover confused cases.

4.5.1.  FraudParameter element

   One value of iodef:MLStringType.  This is the lure used to attract
   victims.  It may be an email subject line, VoIP lure, link in an IM
   message, the CVE or malware identifier, 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.

4.6.  PhishNameRef element

   Zero or one value of STRING.  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 collaborating with other
   parties, the media, or engaging in public education.

4.7.  PhishNameLocalRef element

   Zero or one value of STRING.  The PhishNameLocalRef element describes
   a local name or Unique-IDentifier (UID) that is used by various
   parties before a commonly agreed term is adopted.  This field allows
   a cross-reference from the submitting organization's system to a
   central repository.

4.8.  FraudedBrandName element

   Zero or more values of STRING.  This is the identifier of the
   recognized brand name or company name used in the phishing activity
   (e.g., XYZ Semiconductor Corp).

4.9.  LureSource element

   One value.  REQUIRED.  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



Cain & Jevans            Expires April 26, 2008                [Page 13]

Internet-Draft          IODEF Phishing Extensions           October 2007


   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)--[ RegistryKeysModified  ]
   +-------------+

           Figure 4.2: The LureSource element


4.9.1.  System element

   One or more values of the iodef:System [IODEF, 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.

4.9.2.  DomainData element

   Zero or more.  The DomainData element describes the registration,
   delegation, and control of a domain used to source the lure.
   Capturing the domain data is very useful when investigating or
   correlating events.

   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..*)--[ DomainContacts ]
   +--------------------+

                Figure 4.3 The DomainData element






Cain & Jevans            Expires April 26, 2008                [Page 14]

Internet-Draft          IODEF Phishing Extensions           October 2007


4.9.3.  Name

   One value of iodef:MLStringType [IODEF, Section 2.4].  The Name
   element is the domain name used in this event.

4.9.4.  DateDomainWasChecked

   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.

4.9.5.  RegistrationDate element

   Zero or one value of DATETIME.  The RegistrationDate element shows
   the date of registration for a domain.

4.9.6.  ExpirationDate element

   Zero or one value of DATETIME.  The ExpirationDate element shows the
   date the domain will expire.

4.9.7.  Nameservers element

   Zero or more sub-elements.  These fields hold nameservers identified
   for this domain.  Each entry is a sequence of DNSNameType and iodef:
   Address pairs as specified below.

4.9.7.1.  Server element

   Zero or more values of iodef:MLStringType.  This field contains the
   DNS name of the domain nameserver.

4.9.7.2.  iodef:Address element

   One Value of Address.  REQUIRED.  This field contains the IP address
   of the domain nameserver.

   The use of one Server value and one Address value, followed by
   multiple empty Server values with Address values is allowable to note
   multiple IPAddreses associated with one DNS entry for the domain
   nameserver.

4.9.8.  DomainContacts element

   Choice of either a SameDomainContact or one or more DomainContact
   elements.  The DomainContacts element allows the reporter to enter
   contact information supplied by the registrar or returned by Whois.



Cain & Jevans            Expires April 26, 2008                [Page 15]

Internet-Draft          IODEF Phishing Extensions           October 2007


   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..*)--[ DomainContact ]
   +----------------+

             Figure 4.4 The DomainContacts element


4.9.8.1.  SameDomainContact

   One iodef:DNSNAME.  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 the
   registrar is identical.

4.9.8.2.  DomainContact Element

   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.

   +--------------------+
   | DomainContact      |
   +--------------------+
   |                    |<>----------[ iodef:ContactName ]
   |                    |<>--(0..*)--[ iodef:Description ]
   | ENUM Role          |<>--(0..*)--[ iodef:RegistryHandle ]
   | ENUM Confidence    |<>--(0..1)--[ iodef:PostalAdress ]
   | ENUM Restriction   |<>--(0..*)--[ iodef:Email ]
   |                    |<>--(0..*)--[ iodef:Telephone ]
   |                    |<>--(0..1)--[ iodef:Fax ]
   |                    |<>--(0..1)--[ iodef:Timezone ]
   +--------------------+

           Figure 4.5: The DomainContact element


   Each Contact has three attributes to capture the sensitivity,
   confidence, and role for which the contact is listed.



Cain & Jevans            Expires April 26, 2008                [Page 16]

Internet-Draft          IODEF Phishing Extensions           October 2007


4.9.8.2.1.  Role attribute

   ENUM.  The role attribute is extended from the iodef:role-ext
   attribute with values identified in [CRISP].  The role-ext value of
   the role attribute should be used, with the role-ext attribute value
   chosen from one of the following values:

   1.   registrant.  This identified Contact is the domain registrant.

   2.   registrar.  This contact identifies the registrar of this
        domain.

   3.   billing.  This entry is the billing or financial contact.

   4.   technical.  This contact deals with technical issues.

   5.   administrative.  This contact handles administrative matters for
        this domain.

   6.   legal.  This entry deals with legal issues for this domain.

   7.   zone.  This entry controls the DNS zone information.

   8.   abuse.  This entry accepts abuse issues.

   9.   security.  This entry accepts security issues.

   10.  domainOwner.  This lists the owner of the domain.

   11.  ipAddressOwner.  This entry identifies the assignee of the IP
        address space.

   12.  hostingProvider.  This contact is the hosting provider of this
        domain.

   13.  other.  This entry does not meet an enumerated value.

4.9.8.2.2.  Confidence attribute

   ENUM.  The Confidence attribute 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, either as non-existent physical
       information or containing real information not associated with
       this domain registration.



Cain & Jevans            Expires April 26, 2008                [Page 17]

Internet-Draft          IODEF Phishing Extensions           October 2007


   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.

   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.

4.9.8.2.3.  Restriction attribute

   Zero or one iodef:restriction attribute [IODEF, as part of Section
   3.2].  The restriction attribute is used to label the sensitivity of
   included information.

4.9.9.  SystemStatus attribute

   ENUM.  The SystemStatus attribute assesses a domain's involvement in
   this event.

   1.  spoofed.  This domain or system did not participate in this
       event, but its address space or DNS name was forged.

   2.  fraudulent.  The system is fraudulently operated.

   3.  innocent-hacked.  The system was compromised and used in this
       event to source the lure.

   4.  innocent-hijacked.  The IP Address or domain name was hijacked
       and used in this event to source of the lure.

   5.  unknown.  No conclusions are inferred from this event.

4.9.10.  DomainStatus attribute

   ENUM.  The DomainStatus attribute describes the registry status of a
   domain at the time of the report.  The below enumerated list is taken
   verbose from the 'domainStatusType' of the Extensible Provisioning
   Protocol[RFC3733] and "Domain Registry Version 2 for the Internet
   Registry Information Service" internet-draft [CRISP].

   1.  reservedDelegation - permanently inactive

   2.  assignedAndActive - normal state




Cain & Jevans            Expires April 26, 2008                [Page 18]

Internet-Draft          IODEF Phishing Extensions           October 2007


   3.  assignedAndInactive - registration assigned but delegation
       inactive

   4.  assignedAndOnHold - dispute

   5.  revoked - database purge pending

   6.  transferPending - change of authority pending

   7.  registryLock - on hold by registry

   8.  registrarLock - on hold by registrar

4.9.11.  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.

   +------------------+
   | IncludedMalware  |
   +------------------+
   |                  |<>--(1..*)--[ Name ]
   |                  |<>--(0..1)--[ Hashvalue ]
   |                  |<>--(0..1)--[ Data ]
   +------------------+

   +-----------------+
   | Hashvalue       |
   +-----------------+
   | ENUM Algorithm  |
   |                 |
   | STRING          |
   +-----------------+

   +---------------------+
   | Data                |
   +---------------------+
   | STRING XORPattern   |<>--(0..1)-+-[ StringData ]
   |                     |           +-[ BinaryData ]
   +---------------------+

       Figure 4.6: The Included Malware element






Cain & Jevans            Expires April 26, 2008                [Page 19]

Internet-Draft          IODEF Phishing Extensions           October 2007


4.9.11.1.  Name element

   One or more value of iodef:MLStringType.  This optional field is used
   to identify the lure malware.

4.9.11.2.  Hashvalue element

   Zero or one value of STRING.  This optional field is used to hold the
   value of a hash computed over the malware executable.

4.9.11.2.1.  Algorithm attribute

   REQUIRED ENUM.  This field from the following list identifies the
   algorithm used to create this hashvalue.

   SHA1.  Hashvalue as defined in[SHA].

4.9.11.3.  Data element

   Zero or one value.  Choice of two elements, below.  The optional Data
   element is used to describe the lure malware.

4.9.11.3.1.  StringData element

   The lure malware is encoded as a String value.

4.9.11.3.2.  BinaryData element

   The lure malware is encoded as a hexBinary encoded value, as defined
   by the XML standard.

4.9.11.3.3.  XORPattern attribute

   STRING.  The Data Element includes an optional 16 hexadecimal
   character XORPattern attribute to support disabling the included
   malware to bypass anti-virus filters.  The default value is
   0x55AA55AA55AA55BB which would be XOR-ed with the malware datastring
   to recover the actual malware.

4.9.12.  FilesDownloaded element

   Zero or One value of STRING.  The FileDownloaded element is a comma-
   separated list where each entry is the name of a file downloaded by
   this lure.  Although this element could be implemented as a sequence
   of individual XML entries, the extra XML overhead was perceived to
   not add any value, so the files are listed in one element.





Cain & Jevans            Expires April 26, 2008                [Page 20]

Internet-Draft          IODEF Phishing Extensions           October 2007


4.9.13.  RegistryKeysModified element

   One value of the Keys sequence.

   The contents of the RegistryKeysModified element are sets of Key
   elements.

   +-----------------------+
   | RegistryKeysModified  |
   +-----------------------+
   |                       |<>--(1..*)--[ Key ]
   +-----------------------+

   +--------------+
   | Key          |
   +--------------+
   |              |<>-----[ Name ]
   |              |<>-----[ Value ]
   +--------------+

       Figure 4.7: The RegistryKeysModified element


4.9.13.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

4.9.13.1.1.  Name element

   One STRING, representing the WINDOWS Operating System Registry Key
   Name.

4.9.13.1.2.  Value element

   One STRING, representing the value of the associated Key

4.10.  OriginatingSensor Element

   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 IDS system) nor is it
   required to be mechanical (e.g., humans are allowed).

   Multiple OriginatingSensor Elements are allowed to support detection
   at mutiple locations.



Cain & Jevans            Expires April 26, 2008                [Page 21]

Internet-Draft          IODEF Phishing Extensions           October 2007


   +---------------------+
   | OriginatingSensor   |
   +---------------------+
   | ENUM OrigSensorType |<>------------[ DateFirstSeen ]
   |                     |<>---(1..*)---[ iodef:System ]
   +---------------------+

           Figure 4.8: The OriginatingSensor element


   The OriginatingSensor requires a type value and identification of the
   entity that detected this fraudulent event.

4.10.1.  OrigSensorType attribute

   ENUM.  REQUIRED.  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

       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 IDS, IPS, or ISP 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.

4.10.2.  DateFirstSeen element

       REQUIRED.  DATETIME.  This is the date and time that this sensor
       first saw this phishing activity.







Cain & Jevans            Expires April 26, 2008                [Page 22]

Internet-Draft          IODEF Phishing Extensions           October 2007


4.10.3.  iodef:System element

       One iodef:System.  This is the IPVersion, IPAddress, and
       optionally, port number of the entity that generated this report.

4.11.  The DCSite element

   Zero or more DCSite elements.  The DCSite captures the type,
   identifier, collection 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 site, 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 element.

   If the DCSite element is present, the DCSite element 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 and either
   blank or using the SameDomainContact element.

   +--------------+
   | DCSite       |
   +--------------+
   | ENUM DCSite  |<>--+--------[ SiteURL ]
   |              |    +--------[ Domain ]
   |              |    +--------[ EmailSite ]
   |              |    +--------[ System ]
   |              |    +--------[ Unknown ]
   |              |<>--(0..1)---[ DomainData ]
   |              |<>--(0..1)---[ iodef:Assessment ]
   +--------------+

        Figure 4.9: The DCSite element


4.11.1.  DCType attribute

   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.




Cain & Jevans            Expires April 26, 2008                [Page 23]

Internet-Draft          IODEF Phishing Extensions           October 2007


   3.  keylogger.  Some form of keylogger is downloaded to the victim.

   4.  automation.  Other forms of automatic data collection, such as
       background OLE automation, are used to capture information.

   5.  unspecified.

4.11.2.  DCSite values

   The DCSite element contains the IPAddress, URL, emailsite, or other
   identifier of the 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 element 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.

   The DCSite element is a choice of:

   1.  SiteURL. anyURI.  This choice supports URIs.

   2.  Domain.  STRING.  This choice allows the entry of a DNS Domain
       name.

   3.  EmailSite.  STRING.  This choice captures either the email
       address of the data collection site.

   4.  iodef:System element [IODEF, Section 3.15].  This choice is
       filled it to capture the IP Address of a site.

   5.  Unknown.  STRING.  The unknown entry is used for exception to the
       preceding choices.

4.11.2.1.  DomainData element

   Zero or One value of DomainData.  This element allows for the
   identification of data associated with the data collection site.

4.11.2.2.  iodef:Assessment element

   Zero or One value of iodef:Assessment.  This element is used to
   designate different confidence levels of multiple-site data
   collectors.







Cain & Jevans            Expires April 26, 2008                [Page 24]

Internet-Draft          IODEF Phishing Extensions           October 2007


4.12.  TakeDownInfo element

   Zero or more TakeDownInfo element.  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
   multiple take down 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, 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 4.10: The TakeDownInfo element

4.12.1.  TakeDownDate

   Zero or one DATETIME.  This is the date and time that take down of
   the collector site occurred.

4.12.2.  TakeDownAgency

   Zero or more STRING.  This is a free form string identifying the
   agency, corporation, or cooperative that performed the take down.

4.12.3.  TakeDownComments

   Zero or more STRING.  A free form field to add any additional details
   of this take down effort or to identify parties that assisted in the
   effort at an ISP, CERT, or DNS Registry.

4.13.  ArchivedData element

   Zero or more values of the ArchivedData element are allowed.







Cain & Jevans            Expires April 26, 2008                [Page 25]

Internet-Draft          IODEF Phishing Extensions           October 2007


   +-------------------+
   | ArchivedData      |
   +-------------------+
   | ENUM type         |<>---(0..1)--[ ArchivedDataURL ]
   |                   |<>---(0..1)--[ ArchivedDataComments ]
   |                   |<>---(0..1)--[ ArchivedData ]
   +-------------------+

            Figure 4.11: The ArchivedData element


   The ArchivedData 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 ArchivedDataInfo 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 web site and has copied the site data into an archive file.

   There are four types of archives currently supported, as specified in
   the type field.

4.13.1.  type attribute

   REQUIRED.  This parameter specifies the type of site data pointed to
   by the ArchivedDataURL, from the following list:

   1.  collectionsite.

   2.  basecamp.

   3.  sendersite.

   4.  credentialInfo.

   5.  unspecified.

4.13.2.  ArchivedDataURL element

   Zero or one value of URL.  As the archive of an entire site can be
   quite large, the ArchivedURL element points to an Internet-based
   server where the actual gzipped 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 gzipped archive file is located.







Cain & Jevans            Expires April 26, 2008                [Page 26]

Internet-Draft          IODEF Phishing Extensions           October 2007


4.13.3.  ArchivedDataComments element

   Zero or one value of STRING.  This field is a free form area for
   comments on the archive and/or URL.

4.13.4.  ArchivedData element

   Zero or one value of xs:Base64Binary.  This field may contain a
   base64 encoded version of the data described in the comment field
   above.

4.14.  RelatedData element

   Zero or more value of anyURI.  This element allows the listing of
   other web or net sites that are related to this incident (e.g.,
   victim site, etc.).

4.15.  CorrelationData element

   Zero or more value of STRING.  Any information that correlates this
   incident to other incidents can be entered here.

4.16.  PRComments element

   Zero or one value of STRING.  This field allows for any comments
   specific to this PhraudReport that does not fit in any other field.

4.17.  EmailRecord element

   Extensions are also made to the iodef:Incident.EventData element to
   include the actual email message received in phishing lure or
   widespread spam emails.  The ability to report spam is included
   within a PhraudReport to support exchanging information about large-
   scale spam activities related to phishing, not necessarily a single
   spam message to a user.  As such the spam reporting mechanism was not
   designed to minimize overhead and processing, but to support other
   widely-used spam reporting formats such as the MAAWG's Abuse
   Reporting Format [ARF].

   Reporting of the actual mail message is supported by choosing one of
   three methods.  First, an ARF message may be included.  Second, the
   message may be included as one large string.  Third, the header and
   body components may be dissected and included as a series of strings.








Cain & Jevans            Expires April 26, 2008                [Page 27]

Internet-Draft          IODEF Phishing Extensions           October 2007


   +--------------------+
   | EmailRecord        |
   +--------------------+
   |                    |<>--------------[ EmailCount ]
   |                    |<>--(0..1)--+---[ Email ]
   |                    |            +---[ Message ]
   |                    |            +---[ ARFText ]
   |                    |<>--(0..1)------[ EmailComments ]
   +--------------------+

   +---------------+
   | Email         |
   +---------------+
   |               |<>---+----------[ EmailHeader ]
   |               |<>--(0..1)------[ EmailBody ]
   +---------------+

   +-------------+
   | EmailHeader |
   +-------------+
   |             |<>--(1..*)--[ Header ]
   +-------------+

             Figure 4.12: The EmailRecord element


4.17.1.  EmailCount

   INTEGER.  REQUIRED.  This field enumerates the number of email
   messages identified in this record detected by the reporter.

4.17.2.  Email Message Inclusion

   The actual wide-spread spam message may be included in a report via
   one of three encodings: an ARF message, one big text blob, or a
   separate header and body element.

4.17.2.1.  Message

   Zero of one value of iodef:MLStringType.  The entire mail message can
   be inserted as one large string.

4.17.2.2.  ARFText

   Zero or one value of STRING.  The Messaging Anti-Abuse Working Group
   (MAAWG) defined a format for sending abuse and list control traffic
   to other parties.  Since many of these reports will get integrated
   into incident processes, the raw Abuse Reporting Format [ARF] may be



Cain & Jevans            Expires April 26, 2008                [Page 28]

Internet-Draft          IODEF Phishing Extensions           October 2007


   inserted into this element.

   The ARF should be encoded as a character string.

4.17.2.3.  Email element

4.17.2.3.1.  EmailHeader Element

   Sequence of Header.  The headers of the phish email are included in
   this element as a sequence of one-line text strings.  There SHALL be
   one EmailHeader element per EmailRecord.

4.17.2.3.1.1.  Header

   iodef:MLStringType.  The header element contains a sequence of email
   header lines, one line per header element.

4.17.2.3.2.  EmailBody Element

   Zero or one value of iodef:MLStringType.  This element contains the
   body of the phish email.  If present, there should be at most one
   EmailBody element per EmailRecord

4.17.2.4.  Message

   iodef:MLStringType.  The entire mail message can be inserted as one
   large string.

4.17.3.  EmailComments Element

   Zero or one value of STRING.  This field contains comments or
   relevant data not placed elsewhere about the phishing or spam email.



















Cain & Jevans            Expires April 26, 2008                [Page 29]

Internet-Draft          IODEF Phishing Extensions           October 2007


5.  IODEF Required Elements

   A report about fraud, spam, or phishing requires certain identifying
   information which 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 or to report widespread
   spam.  The required attributes are a combination of those required by
   the base IODEF element and those required by this document.
   Attributes identified as required SHALL be populated in conforming
   phishing activity reports.

   The following table is a visual description of the IODEF-Document
   required fields.

5.1.  Fraud or Phishing Report

   A compliant IODEF PhraudReport is SHALL contain the following element
   and attributes:

      Incident

           @purpose

           IncidentID

           ReportTime

           Assessment -> Confidence

           Contact -> Role

           Contact -> Type

           Contact -> Name

           EventData

               DetectTime

               AdditionalData

                   PhraudReport

                       FraudType

                       FraudedBrandName




Cain & Jevans            Expires April 26, 2008                [Page 30]

Internet-Draft          IODEF Phishing Extensions           October 2007


                       LureSource

                       OriginatingSensor

5.2.   Wide-Spread Spam Report

   An IODEF PhraudReport compliant Spam Activity Report SHALL contain
   the following elements and attributes:

      Incident

           @purpose

           IncidentID

           ReportTime

           Assessment -> Confidence

           Contact -> Role

           Contact -> Type

           Contact -> Name

           EventData

               DetectTime

               AdditionalData

                   PhraudReport

                       FraudType = spamreport

                       LureSource

                       OriginatingSensor

                       EmailRecord

5.3.  Guidance on Usage

   It may be apparent that the mandatory attributes for a phishing
   activity report 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



Cain & Jevans            Expires April 26, 2008                [Page 31]

Internet-Draft          IODEF Phishing Extensions           October 2007


   sensitive can be marked as such using the restriction parameter of
   each data element.

   The reporting party is advised to supply as much information abut the
   event as possible -- or even more -- as the information may be
   volatile and not recoverable in the future to answer investigation
   questions or to perform correlation with other events.












































Cain & Jevans            Expires April 26, 2008                [Page 32]

Internet-Draft          IODEF Phishing Extensions           October 2007


6.  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 environment.

   Organizations that exchange data using this document are URGED to
   develop operating procedures that document the following areas of
   concern.

6.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..

6.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 to not 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            Expires April 26, 2008                [Page 33]

Internet-Draft          IODEF Phishing Extensions           October 2007


7.  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 "Author's Address" 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 "Author's Address" section of this
       document.

       XML: See the "Phishing Extensions Schema Definition" in the
       <Appendix A> section of this document.




























Cain & Jevans            Expires April 26, 2008                [Page 34]

Internet-Draft          IODEF Phishing Extensions           October 2007


8.  Contributors

   The extensions are an outgrowth of the Anti-Phishing Working Group
   (APWG) activities in data collection and sharing of phishing and
   other ecrime-ware.

   This document has received significant assistance from two groups
   addressing the phishing problem: members of the Anti-Phishing Working
   Group and participants in the Financial Services Technology
   Consortium's Counter-Phishing project.









































Cain & Jevans            Expires April 26, 2008                [Page 35]

Internet-Draft          IODEF Phishing Extensions           October 2007


9.  References

9.1.  Normative References

   [RFC-IODEF]
              Meijer, J., Danyliw, R., and Y. Demchenko, "The Incident
              Object Description Exchange Format Data Model and XML
              Implementation", August 2007.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC3688]  Mealing, M., "The IETF XML Registry", RFC 3688,
              January 2004.

   [SHA]      National Institute of Standards and Technology, U.S.
              Department of Commerce, "Secure Hash Standard",
              FIPS 180-1, May 1994.

9.2.  Informative References

   [ARF]      The Messaging Anti-Abuse Working Group (MAAWG), "Abuse
              Reporting Format", May 2005.

   [CRISP]    Newton, L. and A. Neves, "Domain Registry Version 2 for
              the Internet Registry Information Service", RFC 3982,
              January 2005.

   [RFC3733]  Hollenbeck, "Extensible Provisioning Protocol (EPP)
              Contact Mapping"", RFC 3733, March 2004.





















Cain & Jevans            Expires April 26, 2008                [Page 36]

Internet-Draft          IODEF Phishing Extensions           October 2007


Appendix A.  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:xsi="http://www.w3.org/2001/XMLSchema-instance"
   xmlns:xs="http://www.w3.org/2001/XMLSchema"
   xmlns:phish="urn:ietf:params:xml:ns:iodef-phish-1.0"
   xmlns:ns="http://www.w3.org/1999/xhtml"
   xmlns:iodef="urn:ietf:params:xml:ns:iodef-1.0"
   xmlns:hfp="http://www.w3.org/2001/XMLSchema-hasFacetAndProperty"
   xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
   <xs:import namespace="urn:ietf:params:xml:ns:iodef-1.0"
             schemaLocation="draft-ietf-inch-iodef-131.xsd"/>

<!--
This Schema complies with draft-cain-postinch-phishingextns-02.txt

==========================================================
===  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="xs:string"/>
      <xs:element minOccurs="0" name="PhishNameLocalRef"
            type="xs:string"/>
      <xs:element minOccurs="0" name="FraudParameter"
            type="iodef:MLStringType"/>
      <xs:element maxOccurs="unbounded" minOccurs="0"
            name="FraudedBrandName" type="xs:string"/>
      <xs:element name="LureSource" maxOccurs="unbounded" minOccurs="1"
            type="phish:LureSource.type" />
      <xs:element name="OriginatingSensor" maxOccurs="unbounded"
            minOccurs="1" type="phish:OriginatingSensor.type" />
      <xs:element name="EmailRecord" maxOccurs="1" minOccurs="0"
            type="phish:EmailRecord.type"/>



Cain & Jevans            Expires April 26, 2008                [Page 37]

Internet-Draft          IODEF Phishing Extensions           October 2007


      <xs:element name="DCSite" maxOccurs="unbounded" minOccurs="0"
            type="phish:DCSite.type"/>
      <xs:element name="TakeDownInfo" minOccurs="0"
            maxOccurs="unbounded" type="phish:TakeDownInfo.type"/>
      <xs:element name="ArchivedData" minOccurs="0"
            maxOccurs="unbounded" type="phish:ArchivedData.type"/>
      <xs:element name="RelatedData" maxOccurs="unbounded"
            minOccurs="0" type="xs:anyURI"/>
      <xs:element minOccurs="0" name="CorrelationData"
            type="xs:string" maxOccurs="unbounded"/>
      <xs:element maxOccurs="1" minOccurs="0" name="PRComments"
            type="xs:string"/>
    </xs:sequence>

    <xs:attribute default="1.0" name="Version" use="optional"/>
    <xs:attribute name="FraudType" type="phish:FraudType.type"
            use="required"/>
  </xs:complexType>
</xs:element>

  <xs:simpleType name="FraudType.type" >
    <xs:restriction base="xs:string">
      <xs:enumeration value="phishemail"/>
      <xs:enumeration value="recruitemail"/>
      <xs:enumeration value="malwareemail"/>
      <xs:enumeration value="fraudsite"/>
      <xs:enumeration value="dnsspoof"/>
      <xs:enumeration value="keylogger"/>
      <xs:enumeration value="ole"/>
      <xs:enumeration value="im"/>
      <xs:enumeration value="cve"/>
      <xs:enumeration value="archive"/>
      <xs:enumeration value="spamreport"/>
      <xs:enumeration value="voip"/>
      <xs:enumeration value="other"/>
      <xs:enumeration value="unknown"/>
    </xs:restriction>
  </xs:simpleType>

<!--
==========================================================
===           End of the Top-Level Element             ===
==========================================================
-->

<!--
==========================================================
===           The Lure Source Element                  ===



Cain & Jevans            Expires April 26, 2008                [Page 38]

Internet-Draft          IODEF Phishing Extensions           October 2007


==========================================================
-->

<xs:complexType name="LureSource.type" mixed="false">
  <xs:sequence>
    <xs:element maxOccurs="unbounded" minOccurs="1" ref="iodef:System"/>
    <xs:element minOccurs="0" ref="phish:DomainData"/>
    <xs:element name="IncludedMalware" minOccurs="0"
          type="phish:IncludedMalware.type"/>
    <xs:element minOccurs="0" name="FilesDownloaded">
      <xs:simpleType>
        <xs:list itemType="xs:string"/>
      </xs:simpleType>
    </xs:element>

    <xs:element minOccurs="0" name="RegistryKeysModified">
      <xs:complexType>
        <xs:sequence>
          <xs:element maxOccurs="unbounded" name="Key">
            <xs:complexType>
              <xs:sequence>
                <xs:element name="Name"/>
                <xs:element name="Value"/>
              </xs:sequence>
            </xs:complexType>
          </xs:element>
        </xs:sequence>
      </xs:complexType>
    </xs:element>
  </xs:sequence>
</xs:complexType>


<!--
===    LureSource sub-elements    ===
-->

<xs:complexType name="IncludedMalware.type" >
  <xs:sequence>
    <xs:element name="Name" type="iodef:MLStringType" />
    <xs:element minOccurs="0" name="Hashvalue">
      <xs:complexType>
        <xs:simpleContent>
          <xs:extension base="xs:string">
            <xs:attribute name="Algorithm" use="required">
              <xs:simpleType>
                <xs:restriction base="xs:string">
                  <xs:enumeration value="SHA1"/>



Cain & Jevans            Expires April 26, 2008                [Page 39]

Internet-Draft          IODEF Phishing Extensions           October 2007


                </xs:restriction>
              </xs:simpleType>
            </xs:attribute>
          </xs:extension>
        </xs:simpleContent>
      </xs:complexType>
    </xs:element>
    <xs:element minOccurs="0" name="Data">
      <xs:complexType>
        <xs:choice>
          <xs:element name="StringData" type="xs:string"/>
          <xs:element name="BinaryData" type="xs:hexBinary"/>
        </xs:choice>
        <xs:attribute default="55AA55AA55AA55BB" name="XORPattern"
                 type="xs:string"/>
      </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:choice>
      <xs:sequence>
        <xs:element name="EmailHeader">
          <!--
            This is an ugly way to deal with multi-line header info.
           -->
          <xs:complexType>
            <xs:sequence>
              <xs:element maxOccurs="unbounded" minOccurs="1"
                    name="Header" type="iodef:MLStringType"/>
            </xs:sequence>
          </xs:complexType>
        </xs:element>
        <xs:element maxOccurs="1" minOccurs="0" name="EmailBody"
                        type="iodef:MLStringType"/>
      </xs:sequence>
      <xs:element minOccurs="0" name="Message"
             type="iodef:MLStringType" maxOccurs="1" />
      <xs:element minOccurs="0" name="ARFText"



Cain & Jevans            Expires April 26, 2008                [Page 40]

Internet-Draft          IODEF Phishing Extensions           October 2007


             type="xs:string" maxOccurs="1" />
    </xs:choice>
    <xs:element maxOccurs="1" minOccurs="0" name="EmailComments"
                    type="xs:string"/>
  </xs:sequence>
</xs:complexType>

<!--
===========================================================
===  The Data Collection Site (DCSite) Info Element     ===
===========================================================
-->

<xs:complexType name="DCSite.type" >
  <xs:sequence>
    <xs:choice>
      <xs:element name="SiteURL">
        <xs:complexType>
          <xs:simpleContent>
            <xs:extension base="xs:anyURI">
              <xs:attribute name="confidence" type="xs:string" />
            </xs:extension>
          </xs:simpleContent>
        </xs:complexType>
      </xs:element>

      <xs:element name="Domain">
        <xs:complexType>
          <xs:simpleContent>
            <xs:extension base="xs:string">
              <xs:attribute name="confidence" type="xs:string" />
            </xs:extension>
          </xs:simpleContent>
        </xs:complexType>
      </xs:element>

      <xs:element name="EmailSite">
        <xs:complexType>
          <xs:simpleContent>
            <xs:extension base="xs:string">
              <xs:attribute name="confidence" type="xs:string" />
            </xs:extension>
          </xs:simpleContent>
        </xs:complexType>
      </xs:element>

      <xs:element ref="phish:System"/>




Cain & Jevans            Expires April 26, 2008                [Page 41]

Internet-Draft          IODEF Phishing Extensions           October 2007


      <xs:element name="Unknown">
        <xs:complexType>
          <xs:simpleContent>
            <xs:extension base="xs:string">
              <xs:attribute name="confidence" type="xs:string" />
            </xs:extension>
          </xs:simpleContent>
        </xs:complexType>
      </xs:element>
    </xs:choice>
    <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>

  <!--
  ===    DCSite sub-elements    ===
  -->

<!-- Redefine iodef:System to include a confidence value -->

<xs:element name="System">
  <xs:complexType>
    <xs:sequence>
      <xs:element ref="iodef:Node"/>
      <xs:element ref="iodef:Service"
                   minOccurs="0" maxOccurs="unbounded"/>
      <xs:element ref="iodef:OperatingSystem"
                   minOccurs="0" maxOccurs="unbounded"/>
      <xs:element ref="iodef:Counter"
                   minOccurs="0" maxOccurs="unbounded"/>
      <xs:element ref="iodef:Description"
                   minOccurs="0" maxOccurs="unbounded"/>
      <xs:element ref="iodef:AdditionalData"
                   minOccurs="0" maxOccurs="unbounded"/>
    </xs:sequence>



Cain & Jevans            Expires April 26, 2008                [Page 42]

Internet-Draft          IODEF Phishing Extensions           October 2007


    <xs:attribute name="restriction"
                   type="iodef:restriction-type"/>
    <xs:attribute name="interface" type="xs:string"/>
    <xs:attribute name="category">
      <xs:simpleType>
        <xs:restriction base="xs:NMTOKEN">
          <xs:enumeration value="source"/>
          <xs:enumeration value="target"/>
          <xs:enumeration value="intermediate"/>
          <xs:enumeration value="sensor"/>
          <xs:enumeration value="infrastructure"/>
          <xs:enumeration value="ext-value"/>
        </xs:restriction>
      </xs:simpleType>
    </xs:attribute>
    <xs:attribute name="ext-category"
                  type="xs:string" use="optional"/>
    <xs:attribute name="spoofed" default="unknown">
      <xs:simpleType>
        <xs:restriction base="xs:NMTOKEN">
          <xs:enumeration value="unknown"/>
          <xs:enumeration value="yes"/>
          <xs:enumeration value="no"/>
        </xs:restriction>
      </xs:simpleType>
    </xs:attribute>
    <xs:attribute name="confidence" type="xs:string"/>
  </xs:complexType>
</xs:element>

<xs:element name="DomainData">
  <xs:complexType>
    <xs:sequence>
      <xs:element maxOccurs="1" name="Name" type="iodef:MLStringType"/>
      <xs:element minOccurs="0" name="DateDomainWasChecked"
                    maxOccurs="1" 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="Nameserver">
        <xs:complexType>
          <xs:sequence>
            <xs:element name="Server" type="iodef:MLStringType"/>
            <xs:element ref="iodef:Address"/>
          </xs:sequence>
        </xs:complexType>
      </xs:element>



Cain & Jevans            Expires April 26, 2008                [Page 43]

Internet-Draft          IODEF Phishing Extensions           October 2007


      <xs:choice id="DomainContacts" minOccurs="0" maxOccurs="1" >
        <xs:element name="SameDomainContact" type="iodef:MLStringType"/>
        <xs:sequence>
          <xs:element maxOccurs="unbounded" minOccurs="1"
                       ref="phish:DomainContact"/>
        </xs:sequence>
      </xs:choice>
    </xs:sequence>

    <xs:attribute name="SystemStatus">
      <xs:simpleType>
        <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>
        <xs:restriction base="xs:string">
          <xs:enumeration value=
                       "reservedDelegation - permanently inactive"/>
          <xs:enumeration value="assignedAndActive - normal state"/>
          <xs:enumeration value=
 "assignedAndInactive - registration assigned but delegation inactive"/>
          <xs:enumeration value="assignedAndOnHold - dispute"/>
          <xs:enumeration value="revoked - database purge pending"/>
          <xs:enumeration value=
                     "transferPending - change of authority pending"/>
          <xs:enumeration value="registryLock - on hold by registry"/>
          <xs:enumeration value="registrarLock - on hold by registrar"/>
        </xs:restriction>
      </xs:simpleType>
    </xs:attribute>
  </xs:complexType>
</xs:element>

<xs:element name="DomainContact" type="phish:DomainContact.type"/>
<!--
<xs:redefine schemaLocation="urn:ietf:params:xml:ns:iodef-1.0" >
   <xs:element name="iodef:Contact"> -->

<xs:complexType name="DomainContact.type" >
  <xs:sequence>



Cain & Jevans            Expires April 26, 2008                [Page 44]

Internet-Draft          IODEF Phishing Extensions           October 2007


    <xs:element ref="iodef:ContactName" minOccurs="0"/>
    <xs:element ref="iodef:Description"
            minOccurs="0" maxOccurs="unbounded"/>
    <xs:element ref="iodef:RegistryHandle"
            minOccurs="0" maxOccurs="unbounded"/>
    <xs:element ref="iodef:PostalAddress" minOccurs="0"/>
    <xs:element ref="iodef:Email" minOccurs="0" maxOccurs="unbounded"/>
    <xs:element ref="iodef:Telephone"
            minOccurs="0" maxOccurs="unbounded"/>
    <xs:element ref="iodef:Fax" minOccurs="0"/>
    <xs:element ref="iodef:Timezone" minOccurs="0"/>
    <xs:element ref="iodef:Contact"
            minOccurs="0" maxOccurs="unbounded"/>
    <xs:element ref="iodef:AdditionalData"
            minOccurs="0" maxOccurs="unbounded"/>
  </xs:sequence>
  <xs:attribute name="role" use="required">
    <xs:simpleType>
      <xs:restriction base="xs:NMTOKEN">
        <xs:enumeration value="creator"/>
        <xs:enumeration value="admin"/>
        <xs:enumeration value="tech"/>
        <xs:enumeration value="irt"/>
        <xs:enumeration value="cc"/>
        <xs:enumeration value="ext-value"/>
        <!-- Identified by phish extensions -->
        <xs:enumeration value="registrant"/>
        <xs:enumeration value="registrar"/>
        <xs:enumeration value="billing"/>
        <xs:enumeration value="technical"/>
        <xs:enumeration value="administrative"/>
        <xs:enumeration value="legal"/>
        <xs:enumeration value="zone"/>
        <xs:enumeration value="abuse"/>
        <xs:enumeration value="security"/>
        <xs:enumeration value="other"/>
        <xs:enumeration value="domainOwner"/>
        <xs:enumeration value="ipAddressOwner"/>
        <xs:enumeration value="hostingProvider"/>
      </xs:restriction>
    </xs:simpleType>
  </xs:attribute>
  <xs:attribute name="ext-role" type="xs:string" use="optional"/>
  <xs:attribute name="type" use="required">
    <xs:simpleType>
      <xs:restriction base="xs:NMTOKEN">
        <xs:enumeration value="person"/>
        <xs:enumeration value="organization"/>



Cain & Jevans            Expires April 26, 2008                [Page 45]

Internet-Draft          IODEF Phishing Extensions           October 2007


        <xs:enumeration value="ext-value"/>
      </xs:restriction>
    </xs:simpleType>
  </xs:attribute>
  <xs:attribute name="ext-type" type="xs:string" use="optional"/>
  <xs:attribute name="restriction" type="iodef:restriction-type"/>
  <xs:attribute name="confidence">
    <xs:simpleType>
      <xs:restriction base="xs:string">
        <xs:enumeration value="known-fraudulent"/>
        <xs:enumeration value="looks-fraudulent"/>
        <xs:enumeration value="known-real"/>
        <xs:enumeration value="looks-real"/>
        <xs:enumeration value="unknown"/>
      </xs:restriction>
    </xs:simpleType>
  </xs:attribute>
</xs:complexType>

<!--
===================================================================
===  The Originating Sensor 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>
     <xs:restriction base="xs:NMTOKENS">
       <xs:enumeration value="web"/>
       <xs:enumeration value="webgateway"/>
       <xs:enumeration value="mailgateway"/>
       <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>

<!--



Cain & Jevans            Expires April 26, 2008                [Page 46]

Internet-Draft          IODEF Phishing Extensions           October 2007


===================================================
===        The Take Down Data structure.        ===
===================================================
-->

<xs:complexType name="TakeDownInfo.type" >
  <xs:sequence>
    <xs:element name="TakeDownDate" type="xs:dateTime"
             minOccurs="0" maxOccurs="1" />
    <xs:element name="TakeDownAgency" type="xs:string"
             maxOccurs="unbounded" minOccurs="0" />
    <xs:element name="TakeDownComments" type="xs:string"
             maxOccurs="unbounded" minOccurs="0" />
  </xs:sequence>
</xs:complexType>

<!--
====================================================
===        The Archived Data Element             ===
====================================================
-->

<xs:complexType name="ArchivedData.type" >
  <xs:sequence>
    <xs:element name="ArchivedDataURL" type="xs:anyURI" minOccurs="0"/>
    <xs:element name="ArchivedDataComments" type="xs:string"
                   minOccurs="0" />
    <xs:element name="ArchivedData" type="xs:base64Binary"
                   minOccurs="0" maxOccurs="1"/>
  </xs:sequence>
  <xs:attribute name="type" use="required">
    <xs:simpleType>
      <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>







Cain & Jevans            Expires April 26, 2008                [Page 47]

Internet-Draft          IODEF Phishing Extensions           October 2007


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: pcain@example.com
   Subject: You have successfully updated your password
   Attachments: updated-password.zip

   Dear user pcain,

   You have successfully updated the password of your Coopercain
   account. If you did not authorize this change or if you need
   assistance with your account, please contact Coopercain customer
   service at: support@coopercain.com

   Thank you for using Coopercain!
   The Coopercain Support Team

   +++ Attachment: No Virus (Clean) +++
   Coopercain Antivirus - www.example.com

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:ns="http://www.w3.org/1999/xhtml"
   xmlns:hfp="http://www.w3.org/2001/XMLSchema-hasFacetAndProperty"
   xmlns:iodef="urn:ietf:params:xml:ns:iodef-1.0"
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xmlns="urn:ietf:params:xml:ns:iodef-1.0"
       xmlns:phish="urn:ietf:params:xml:ns:iodef-phish-1.0" >
     <Incident purpose="other">
       <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"></Impact>
         <Confidence rating="high"></Confidence>
       </Assessment>
       <Contact role="creator" type="person">



Cain & Jevans            Expires April 26, 2008                [Page 48]

Internet-Draft          IODEF Phishing Extensions           October 2007


         <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="phishemail">
             <phish:FraudParameter>
               Subject: You have successfully updated your password
             </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.18</Address>
                 </Node>
               </System>
              </phish:OriginatingSensor>
              <phish:EmailRecord>
               <phish:EmailCount>1</phish:EmailCount>
               <phish:Message>
   "Return-path: &lt;support@coopercain.com&gt;"
   Envelope-to: pcain@coopercain.com Delivery-date: Fri, 10 Jun 2005
   15:52:11-0400 Received: from dsl231-063-162.sea1.dsl.example.net
   ([192.0.2.18] helo=coopercain.com) by mail06.coopercain.com
   with esmtp (Exim) id 1DgpXy-0002Ua-IR for pcain@coopercain.com;
   Fri, 10 Jun 2005 15:52:10-0400 From: support@coopercain.com To:
   pcain@coopercain.com Subject: You have successfully updated yourn
    password Date: Fri, 10 Jun 2005 12:52:00 -0700 MIME-Version: 1.0
   Content-Type: multipart/mixed;

   boundary="----=_NextPart_000_0008_0911068B.E7EB6D2A" X-Priority: 3
   X-MSMail-Priority: Normal X-EN-OrigIP: 192.0.2.18
   X-EN-OrigHost: dsl231-063-162.sea1.dsl.example.net
   X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on
   Scan18.example.net X-Spam-Level: ***** X-Spam-Status: No,



Cain & Jevans            Expires April 26, 2008                [Page 49]

Internet-Draft          IODEF Phishing Extensions           October 2007


    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@coopercain.com Sent: Friday, June 10, 2005 3:52 PM
   To:pcain@coopercain.com Subject: You have successfully updated
   your password Attachments: updated-password.zip

   Dear user pcain,
   You have successfully updated the password of your Coopercain
   account. If you did not authorize this change or if you need
   assistance with your account, please contact Coopercain customer
   service at: support@coopercain.com Thank you for using Coopercain!

   The Coopercain Support Team +++ Attachment: No Virus (Clean) +++
   Coopercain Antivirus - www.coopercain.com
               </phish:Message>
             </phish:EmailRecord>
           </phish:PhraudReport></AdditionalData>
       </EventData>
     </Incident>
   </IODEF-Document>






























Cain & Jevans            Expires April 26, 2008                [Page 50]

Internet-Draft          IODEF Phishing Extensions           October 2007


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@paypal.com>
   Envelope-to: pcain@coopercain.com
   Delivery-date: Tue, 13 Jun 2006 05:37:22 -0400
   Received: from mail15.yourhostingaccount.com ([10.1.1.161]
    helo=mail15.yourhostingaccount.com)
    by mailscan38.yourhostingaccount.com with esmtp (Exim)
    id 1Fq5Kr-0005wU-LT for pcain@coopercain.com; Tue, 13 Jun 2006
    05:37:21 -0400
   Received: from [24.147.114.61] (helo=TSI)
   by mail15.yourhostingaccount.com with
    esmtp (Exim) id 1Fq5Bj-0006dv-6b
   for pcain@coopercain.com; Tue, 13 Jun 2006 05:37:21 -0400
   Received: from User ([66.59.189.157]) by TSI with
    Microsoft SMTPSVC(5.0.2195.6713);
   Tue, 13 Jun 2006 02:24:30 -0400
   Reply-To: <nospa@nospa.us>
   From: "PayPal"<service@paypal.com>
   Subject: * * * Update & Verify Your PayPal 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@paypal.com
   X-EN-OrigIP: 192.0.2.1
   X-EN-OrigHost: unknown

   PayPal<http://www.paypal.com/images/paypal_logo.gif>
    <http://www.paypal.com/images/pixel.gif>
    <http://www.paypal.com/images/pixel.gif>
    <http://www.paypal.com/images/pixel.gif>
   Account Update Request





Cain & Jevans            Expires April 26, 2008                [Page 51]

Internet-Draft          IODEF Phishing Extensions           October 2007


   Dear PayPal. member:,

   You are receiving this notification because PayPal 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 PayPal account can be done at any time by
   clicking on the link shown below
   http://www.paypal.com/cgi-bin/webscr?cmd=_login-run
   <http://217.136.251.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 which is at
   the upper right hand side of the PayPal website. To report errors in
   your statement or make inquiries, click the Contact Us link in the
   footer on any page of the PayPal website, call our Customer Service
   center at (401) 938-3600, or write us at:

   PayPal, Inc.
   P.O. Box 45950
   Omaha, NE 68145

   Sincerely,

   PayPal

    <http://www.paypal.com/images/dot_row_long.gif>


C.2.  Phishing Report





   <?xml version="1.0" encoding="UTF-8"?>
   <IODEF-Document xmlns="urn:ietf:params:xml:ns:iodef-1.0"
   xmlns:ns="http://www.w3.org/1999/xhtml"
   xmlns:hfp="http://www.w3.org/2001/XMLSchema-hasFacetAndProperty"
   xmlns:iodef="urn:ietf:params:xml:ns:iodef-1.0"
   xmlns:phish="urn:ietf:params:xml:ns:iodef-phish-1.0"



Cain & Jevans            Expires April 26, 2008                [Page 52]

Internet-Draft          IODEF Phishing Extensions           October 2007


   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"  lang="">
     <Incident purpose="mitigation" restriction="private">
       <IncidentID name="coopercain.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"></Impact>
         <Confidence rating="numeric">85</Confidence>
       </Assessment>
       <Contact role="creator" type="person">
         <ContactName>patcain</ContactName>
         <Email>pcain@coopercain.com</Email>
       </Contact>
       <EventData>
         <DetectTime>2006-06-13T05:37:21-04:00</DetectTime>
         <AdditionalData dtype="xml">
           <phish:PhraudReport FraudType="phishemail">
             <phish:FraudParameter>
                   * * * Update &amp; Verify Your PayPal Account * * *
             </phish:FraudParameter>
             <phish:FraudedBrandName>PayPal</phish:FraudedBrandName>
             <phish:LureSource>
               <System category="source">
                 <Node>
                   <Address>192.0.2.2</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"></NodeRole>
                 </Node>
               </System>
             </phish:OriginatingSensor>
             <phish:EmailRecord>
               <phish:EmailCount>1</phish:EmailCount>
               <phish:Message>Return-path: &lt;service@paypal.com&gt;
   Envelope-to: pcain@coopercain.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@coopercain.com;
    Tue, 13 Jun 2006 05:37:21 -0400



Cain & Jevans            Expires April 26, 2008                [Page 53]

Internet-Draft          IODEF Phishing Extensions           October 2007


   Received: from [192.0.2.2] (helo=bob) by mail15.example.com
   with esmtp (Exim) id 1Fq5Bj-0006dv-6b for pcain@coopercai
   n.com; Tue, 13 Jun 2006 05:37:21 -0400
   Received: from User ([192.0.2.4]) by Bob with Microsoft SMTPSV
   C(5.0.2195.6713); Tue, 13 Jun 2006 02:24:30 -0400 Reply-To: &lt;no
   spa@nospa.us&gt;
   From: "PayPal"&lt;service@paypal.com&gt;
   Subject: * * * Update &amp; Verify Your PayPal 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&gt;
   X-OriginalArrivalTime: 13 Jun 2006 06:24:30.0218 (UTC) FILETIME=[07
   2A66A0:01C68EB2]
   X-EN-OrigSender: service@paypal.com X-EN-OrigIP: 192.0.2.4
   X-EN-OrigHost: unknown PayPal&lt;http://www.paypal.com/images/paypal
   _logo.gif&gt; &lt;http://www.paypal.com/images/pixel.gif&gt; &lt;htt
   p://www.paypal.com/images/pixel.gif&gt; &lt;http://www.paypal.com/im
   ages/pixel.gif&gt; Account Update Request Dear PayPal. member:, You
   are receiving this notification because PayPal is required by law to
    notify you, that you urgently need to update your online account st
   atement, due to high risks of fraud intentions.
   The updating of your PayPal account can be done at any time by click
   ing on the link shown below http://www.paypal.com/cgi-bin/webscr?cmd
   =_login-run &lt;http://217.136.251.41:8080/.cgi-bin/.webscr/.secure-
   login/%20/%20/.payp al.com/index.htm&gt; Once you log in,update your
    account information. After updating your account click on the Histo
   ry sub tab of your Account Overview page to see your most recent sta
   tement. If you need help with your password, click the Help link whi
   ch is at the upper right hand side of the PayPal website. To report
   errors in your statement or make inquiries, click the Contact Us lin
   k in the footer on any page of the PayPal website, call our Customer
    Service center at (402) 938-3630, or write us at: PayPal, Inc. P.O.
    Box 45950 Omaha, NE 68145 Sincerely, PayPal &lt;http://www.paypal.c
   om/images/dot_row_long.gif&gt;</phish:Message>
             </phish:EmailRecord>
             <phish:DCSite DCType="web">
                 <phish:SiteURL>
                   http://217.136.251.41:8080/.cgi-bin/.webscr/.secure-
                   login/%20%20/.paypal.com/index.htm
                 </phish:SiteURL>
                 <phish:DomainData
                     DomainStatus="assignedAndActive - normal state"
                     SystemStatus="unknown">
                   <phish:Name>adsl.skynet.be</phish:Name>



Cain & Jevans            Expires April 26, 2008                [Page 54]

Internet-Draft          IODEF Phishing Extensions           October 2007


                   <phish:DateDomainWasChecked>
                     2006-06-14T13:05:00-05:00
                   </phish:DateDomainWasChecked>
                   <phish:RegistrationDate>
                     2000-12-13T00:00:00</phish:RegistrationDate>
                   <phish:Nameserver>
                     <phish:Server>ns1.example.net</phish:Server>
                     <Address>192.0.2.18</Address>
                   </phish:Nameserver>
                 </phish:DomainData>
             </phish:DCSite>
           </phish:PhraudReport></AdditionalData>
       </EventData>
     </Incident>
   </IODEF-Document>




































Cain & Jevans            Expires April 26, 2008                [Page 55]

Internet-Draft          IODEF Phishing Extensions           October 2007


Authors' Addresses

   Patrick Cain
   The Cooper-Cain Group, Inc.
   P.O. Box 400992
   Cambridge, MA
   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            Expires April 26, 2008                [Page 56]

Internet-Draft          IODEF Phishing Extensions           October 2007


Full Copyright Statement

   Copyright (C) The IETF Trust (2007).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.


Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).





Cain & Jevans            Expires April 26, 2008                [Page 57]


Html markup produced by rfcmarkup 1.109, available from https://tools.ietf.org/tools/rfcmarkup/