INCH P. Cain
Internet-Draft The Cooper-Cain Group
Expires: May 4, 2006 D. Jevans
The Anti-Phishing Working Group
October 31, 2005
Extension to IODEF-Document Class for Phishing, Fraud, and Other Non-
Network Layer Reports
draft-ietf-inch-phishingextns-02
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 May 4, 2006.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
This document extends the INCH XML incident reporting format for
reporting phishing, fraud, other types of electronic crime, and
widespread spam attacks and incidents. Although the term "phishing
attack" is used, the data format extensions are flexible enough to
support information gleaned from activities throughout the entire
phishing life cycle and extensible enough to be used for other types
Cain & Jevans Expires May 4, 2006 [Page 1]
Internet-Draft IODEF Fraud Report Extensions October 2005
of electronic crime incidents, along with simple spam. The
extensions support very simple reporting as well as optional fields
for detailed, forensic reports, and supports single phish/fraud
incidents as well as consolidated reports of multiple phish
incidents.
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[RFC2119].
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Why a Common Report Format is Needed . . . . . . . . . . . 3
1.2. Relation to the INCH IODEF Data Model . . . . . . . . . . 4
2. The Elements of Phishing/Fraud Activity . . . . . . . . . . . 6
3. Fraud Actvitiy Reporting via an IODEF-Document Incident . . . 7
4. PhraudReport Element Definitions . . . . . . . . . . . . . . . 9
4.1. Version parameter . . . . . . . . . . . . . . . . . . . . 9
4.2. Identifying A Fraud campaign . . . . . . . . . . . . . . . 10
4.3. FraudedBrandName Element . . . . . . . . . . . . . . . . . 12
4.4. The Data Collection Site Element (DCSite) . . . . . . . . 12
4.5. OriginatingSensor Element . . . . . . . . . . . . . . . . 13
4.6. TakeDownInfo Element . . . . . . . . . . . . . . . . . . . 15
4.7. ArchivedData Element . . . . . . . . . . . . . . . . . . . 15
4.8. RelatedData Element . . . . . . . . . . . . . . . . . . . 16
4.9. CorrelationData Element . . . . . . . . . . . . . . . . . 16
4.10. PRComments Element . . . . . . . . . . . . . . . . . . . . 16
4.11. EmailRecord Element . . . . . . . . . . . . . . . . . . . 16
5. IODEF Required Elements . . . . . . . . . . . . . . . . . . . 18
5.1. Fraud or Phishing Report . . . . . . . . . . . . . . . . . 18
5.2. Wide-Spread Spam Report . . . . . . . . . . . . . . . . . 19
5.3. Guidance on Usage . . . . . . . . . . . . . . . . . . . . 20
6. Security Considerations . . . . . . . . . . . . . . . . . . . 21
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 23
9. Normative References . . . . . . . . . . . . . . . . . . . . . 23
Appendix A. Phishing Extensions XML Schema . . . . . . . . . . . 24
Appendix B. Examples of Complete Fraud Activity Reports . . . . . 31
B.1. Sample Phish/Malware Email Report . . . . . . . . . . . . 31
B.2. Received Email . . . . . . . . . . . . . . . . . . . . . . 31
B.3. Generated Report . . . . . . . . . . . . . . . . . . . . . 31
Appendix C. Sample Spam Report . . . . . . . . . . . . . . . . . 34
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 35
Intellectual Property and Copyright Statements . . . . . . . . . . 36
Cain & Jevans Expires May 4, 2006 [Page 2]
Internet-Draft IODEF Fraud Report Extensions October 2005
1. Introduction
Deception activities on the Internet, such as receiving an email
purportedly from a bank requesting you to confim your account
information, are an expanding attack type in the Internet. For this
document, the two terms phishing and fraud are used interchangeably
and characterize as 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). A
successful phishing attack on an individual allows the phisher (i.e.,
attacker) to exploit the individual's credentials for financial or
other gain. Early phishing attacks were directed at individuals via
email as a ruse from a bank security department, requesting the
user's ATM number and PIN. Once phished, the bank account could be
used by the phisher to perpetrate additional fraud, money laundering,
or plain emptying of the account. As individuals became more aware
of phishing tactics, the phishers have evolved into using more
complex and stealthier technologies, and have targeted institutions
such as ISPs and corporations other than banks. Other miscreants are
also using these same techniques for other types of Internet attacks.
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 data collected allows them to better plan
out mitigation activities and to initiate or assist in prosecution of
the attacker. Early on it became obvious that a common format for
the data reported or exchanged between these parties was necessary.
The IETF INCH XML format was selected for this use as it was already
becoming a standard way of sharing this type of information.
Although originally designed for network-layer incident sharing
(e.g., DoS attacks, compromised computers) the INCH format can be
extended quite easily to support other incident profiles, as we show
in this document.
The use of a common format will help organizations integrate multiple
product outputs into a cohesive single attack view. It will also
allow for the introduction of advanced services such as wholly
automatic local notifications and usable data mining.
The accumulation and correlation of information is very important
when dealing with security incidents. In phishing attacks
specifically, the attack source may be misrepresented or forged. the
targeted organization may not even be aware of the ongoing attack.
Cain & Jevans Expires May 4, 2006 [Page 3]
Internet-Draft IODEF Fraud Report Extensions October 2005
Third parties aware of the attack may wish to notify the targeted
organization or a central notification service. The targeted
organization's internal monitoring systems may also detect the attack
and wish to take mitigation steps. Without this document, there is
no recognized standard format to express the detection of a phishing
attack or to exchange detailed information about it. For an
organization that employs multi anti-phishing technologies,
correlating data from multiple vendors or products is close to
impossible as the data is reported in multiple, mostly incompatible,
formats.
This document defines a data format extension to IODEF that is used
to capture relevant information from a phishing attack and shared,
correlated, or to populate a database. Additionally, the use of
products that export information in this format will allow an
organization to correlate and analyze phishing information across
their organization. Although targeted at both the accumulation of
phishing attack information from a single institution and a means of
sharing attack information between cooperating parties, the actual
information sharing process and related political challenges are not
covered in this document.
1.2. Relation to the INCH IODEF Data Model
Instead of defining report format and language from scratch, the
phishing activities information is encoded as XML extensions to the
Incident Object Description Exchange Format Data Model [IODEF]. The
use of this already existent and operational format, based on the
Intrusion Detection Message Exchange Format [IDMEF], allows for
quicker vendor adoption and reuse of existing tools in organizations.
To reduce duplication and to be compatible with forward modifications
to the base IODEF definitions, this document only identifies
additional structures necessary for exchnaing phishing and e-crime
information.
The goal of using a common format is to be simple and efficient, and
to support additional data to be included to provide a complete
picture of the event, when necessary. One criticism of the IODEF
format is that it is too cumbersome (i.e., large and complex) to be
used in an efficient manner for something as simple as fraud events.
The IODEF format has very few required elements to allow for
efficiency, but allows extremely verbose elements to be used if
supporting data is available. This flexibility allows the IODEF
formats to be used in a wide range of event reports but only requires
the product developer to support one format standard.
Cain & Jevans Expires May 4, 2006 [Page 4]
Internet-Draft IODEF Fraud Report Extensions October 2005
1.2.1. The IODEF Extensions for Fraud
In general, an IODEF incident report contains detailed incident-
specific data which populates an EventData Structure. That data is
then incorporated, either singularly or in aggregation, with
additional summary and contact data, into an Incident structure.
A Fraud Activity Report is an instance of an XML IODEF-Document with
added EventData and AdditionalData elements. It contains the
Incident structure and additional fields in the EventData specific to
phishing and fraud (the PhraudReport). Phishing activity may include
multiple email, instant message, or network messages, scattered over
various times, locations, and methodologies. The new EventData
fields are combined into a Fraud Activity Report and includes
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 crdential collector. As a phishing
attack may generate multiple reports to an incident team, the Fraud
Activity Reports may be combined into one EventData structure.
Multiple EventData structures may be combined into one Incident
Report. And one IODEF Incident report ma record one or more
individual phishing events and may include multiple EventData
elements.
This document defines new attributes for the EventData and Record
Item IODEF XML elements and identifies the Fraud Activity Report
required attributes. The Appendices contain sample Fraud Activity
Reports and a complete Schmea and Document Type Definition.
The IODEF Extensions defined in this document comply with section4,
"Extending the IODEF Format" in [IODEF].
Cain & Jevans Expires May 4, 2006 [Page 5]
Internet-Draft IODEF Fraud Report Extensions October 2005
2. The Elements of Phishing/Fraud Activity
+-----------+ +------------------+
| Fraudster |<---<-- | Collection Point |<---O--<----<-----\
+----+------+ +------------------+ | |
^ | |
| +--|-----+ ^
| | Sensor | Credentials
| +-|------+ |
| +---------------+ | +-------+
\--->---| Attack Source |--Phish-->-----O------> | User/ |
+---------------+ |Victim |
+-------+
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, where the phishing email, virus, trojan, or
other attack is generated.
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, which is something that detects the fraud/phish
attempt or success. This element may be an intrusion detection
system, firewall, filter, email gateway, or human.
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 May 4, 2006 [Page 6]
Internet-Draft IODEF Fraud Report Extensions October 2005
3. Fraud Actvitiy Reporting via an IODEF-Document Incident
A Fraud Activity Report is an instance of an XML IODEF-Document with
added EventData, AdditionalData elements. The added elements compose
a PhraudReport Element. Required information with many optional
items are populated into the PhraudReport structure to form a Fraud
Activity Report. To facilitate completeness, the report originator
should fill out all mandatory items and as many as necessary optional
Incident element fields, to stay consistent with the IODEF-Document
structure.
This document defines new EventData IODEF XML elements; then
identifies attributes that are required in a compliant Fraud Activity
Report. The Appendices contain sample Fraud Activity Reports and the
complete XML Document Type Definition and schema.
The Incident element with fraud extensions is summarized below. It
provides a standardized representation for commonly exchanged
incident data and associates a CSIRT assigned unique identifier with
the described activity.
+-------------------+
| Incident |
+-------------------+
| ENUM purpose |<>----------[ IncidentID ]
| ENUM restriction |<>--{0..1}--[ AlternativeID ]
| |<>--{0..1}--[ RelatedActivity ]
| |<>--{0..*}--[ Description ]
| |<>--{1..*}--[ Assessment ]
| |<>--{0..*}--[ Method ]
| |<>--{0..1}--[ DetectTime ]
| |<>--{0..1}--[ StartTime ]
| |<>--{0..1}--[ EndTime ]
| |<>----------[ ReportTime ]
| |<>--{1..*}--[ Contact ]
| |<>--{0..*}--[ Expectation ]
| |<>--{0..1}--[ History ]
| |<>--{0..*}--[ EventData ]
| | --> [ AdditionalData ]
| | --> PhraudReport (added)
+------------------+
Figure 1. The IODEF XML Incident Element (modified)
A Fraud Activity Report is composed of one IODEF Incident element,
containing one or more EventData elements that contain one or more
PhraudReport elements. This document defines the PhraudReport
element for the Incident.EventData.AdditionalData element comprising
Cain & Jevans Expires May 4, 2006 [Page 7]
Internet-Draft IODEF Fraud Report Extensions October 2005
of phishing and fraud-related information that does not map to
existing Incident or EventData attributes. Some additional
attributes are defined to capture electronic mail header and routing
information.
One Incident report may contain information on multiple incidents.
After the report identification information listed in the Incident
element, each individual event is detailed within a single EventData
structure.
Cain & Jevans Expires May 4, 2006 [Page 8]
Internet-Draft IODEF Fraud Report Extensions October 2005
4. PhraudReport Element Definitions
A PhraudReport consists of an extension to the Incident
AdditionalData Element. The elements of the PhraudReport will
identify and capture information related to the four components of
fraud activity. Other forensic information and commentary can be
added by the reporter as necessary to show relation to other events,
the output of an investigation, or for archival purposes. A
PhraudReport element is structured as follows.
+--------------------------+
| EventData.AdditionalData |
+--------------------------+
| ENUM type (9 = xml) |<>---------[ PhraudReport ]
| STRING meaning (xml) |
+--------------------------+
+-----------------+
| PhraudReport |
+-----------------+
| ENUM Version |<>--(0..*)--[ PhishNameRef ]
| ENUM FraudType |<>--(0..*)--[ PhishNameLocalRef ]
| |<>--(0..*)--[ FraudParameter ]
| |<>--(0..*)--[ FraudedBrandName ]
| |<>--(1..*)--[ LureSource ]
| |<>----------[ OriginatingSensor ]
| |<>--(0..1)--[ EmailRecord ]
| |<>--(0..*)--[ DCSite ]
| |<>--(0..*)--[ TakeDownInfo ]
| |<>--(0..*)--[ ArchivedData ]
| |<>--(0..*)--[ RelatedData ]
| |<>--(0..*)--[ CorrelationData ]
| |<>--(0..1)--[ PRComments ]
+-----------------+
Figure 2. The PhraudReport Extensions to the INCH XML
Incident.AdditionalData Element
The components of a PhraudReport are introduced in functional
grouping as some parameters are related and some elements may not
make sense stand-alone.
4.1. Version parameter
STRING. The version shall be the value 1.0 to be compliant with this
document.
Cain & Jevans Expires May 4, 2006 [Page 9]
Internet-Draft IODEF Fraud Report Extensions October 2005
4.2. Identifying A Fraud campaign
At times it may be useful to identify a specific phish or fraud for
future analysis, much like the Anti-Virus Vendors identify certain
viruses. A specific phish/fraud activity can be identified using a
combination of the FraudType, FraudParameter, and PhishRefName
elements.
4.2.1. FraudType Parameter
ENUM. The FraudType attribute contains a number representing the
type of fraud attempted. The Email element has been separated into
multiple numbers to support the primary types of email.
1. PhishEmail, and the FraudParameter is 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, and 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, and 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, no FraudParameter. This identifies a known fraudulent
site that does not necessarily send spam lures.
5. DNSspoof, with the malware name as a parameter. This is used for
a spoofed DNS (e.g., malware changes localhost file so visits to
www.example.com go to another IP address).
6. Keylogger, with the malware name as the FraudParameter.
7. OLE, no parameter. This identifies background Microsoft Object
Linking and Embedding (OLE) information.
8. IM. The subject line parameter may be the malicious instant
message (IM) link supplied to the user.
9. CVE, with the Common Vulnerability and Exposures project (CVE)
number as the FraudParameter.
10. SiteArchive, with the data archived from the phishing server
Cain & Jevans Expires May 4, 2006 [Page 10]
Internet-Draft IODEF Fraud Report Extensions October 2005
placed in the ArchiveInfo element.
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. Unknown.
When a FraudParameter is required, it is one of the following values:
SubjectLine element
STRING. This is the subject line of the email lure.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 PhishParameter field.
MalwareName element
STRING. This is the name of the malware that installed the
keylogger or DNSspoofer.
CVENumber element
STRING. This is the CVE identifier of this exploit used to
phish.
4.2.2. LureSource Element
SOURCE. Many times the phishing, spam, or fraud lure email is
received from a spoofed IP address. If the real IP Address can be
ascertained it should be populated into this field. A spoofed
address may also be entered, but the spoofed attribute SHALL be set.
The field is an IODEF Source element to capture the Address and to
allow for support of IPv6 and port numbers. An additional text
string is provided to capture domain or host information at the time
of the event.
4.2.3. PhishNameRef Element
STRING. This value is a friendly-name for this fraud event. It may
be agreed upon by vendor collaboration to note a common name for a
given phish attack or "campaign". The agreed upon identifier could
be useful in collaboration, support, media and public education.
4.2.4. PhishNameLocalRef Element
STRING. Many contributors will have a local reference name or
Cain & Jevans Expires May 4, 2006 [Page 11]
Internet-Draft IODEF Fraud Report Extensions October 2005
Unique-IDentifier (UID) that will be used before a commonly agreed
term is adopted in PhishNameRef. This field allows a cross-reference
from the submitting organization's system to the central repository.
4.3. FraudedBrandName Element
STRING. This is the identifier of the recognized brandname or
company name used to launch the phishing activity. Some schemes,
such as those enticing "mules" for money laundering or related
activities, may use a lesser known or fictitious brand [e.g., xyz
semiconductor company]. Those brand identifiers should also populate
this field.
4.4. The Data Collection Site Element (DCSite)
This section captures the type, identifier, collection location, and
other pertinent information about the credential gathering process by
the fraudster. The data collection site is identified by three
elements: the type of collector activity, what type of collector
site, and the network address of the collector site (i.e., URL, IP
address, etc).
If the DCSite element is present, the DCSiteType element is required.
Multiple DCSiteData elements are allowed.
+-------------+
| DCSite |
+-------------+
| ENUM DCType |<>--(0..*)---[ DCSiteData ]
+-------------+
+------------------+
| DCSiteData |
+------------------+
| ENUM DCSiteType |<>-----------[ sireURL ]
| |<>-----------[ emailsite ]
| |<>-----------[ Source ]
| |
+------------------+
4.4.1. DCType Parameter
ENUM. This element identifies the method of data collection, as
determined by analyzing the victim computer, lure, or malware, and
are selected from the following list. This element is coupled with
the DCSiteData element to identify the data collection site.
Cain & Jevans Expires May 4, 2006 [Page 12]
Internet-Draft IODEF Fraud Report Extensions October 2005
1. Web. The user is redirected to a website to collects the
data.
2. Email Form. The victiis sent to a form-to-fill-out.
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 infomration.
5. Unspecified.
4.4.2. DCSiteData Element
This element contains the IPAddress, URL, or other identification of
the data collection site as selected by the DCType Parameter.
4.4.2.1. DCSiteType Parameter
ENUM. This parameter tags the network address and other information
in the DataCollectionSiteData element.
1. Web. Data from the victim is collected on a website. The
website URL is included in the DCSitePointer.
2. Email. The victim emails credentials to the collection site.
The email server DNS name is in the DCSitePointer.
3. IODEF.SOURCE Element. This collection site uses other
protocols to gather data from the victim. The DCSitePointer field
is an IODEF Source Element, holding the IP Version Protocol,
IPAddress, and Port number of the collection site. The Protocol
field defaults to TCP, if absent.
4. Unknown. The DCSitePointer data should be verbose.
4.5. OriginatingSensor Element
The OriginatingSensor element contians the identification and
cognizant data of the network element that detected this fraud
activity. Note that the network element does not have to be in 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 Originating Sensor Elements are allowed.
Cain & Jevans Expires May 4, 2006 [Page 13]
Internet-Draft IODEF Fraud Report Extensions October 2005
+---------------------+
| OriginatingSensor |
+---------------------+
| ENUM OrigSensorType |<>------------[ DateFirstSeen ]
| |<>---(0..1)---[ Name ]
| |<>---(1..*)---[ Sourve ]
| |<>---(0..1)---[ Location ]
+---------------------+
The OriginatingSensor requires a type value and identification of the
entity that generated this report.
4.5.1. OrigSensorType Parameter
Type parameter is an ENUM from the following:
1. Web. A web server or service.
2. WebGateway, as in a proxy or firewall.
3. MailGateway.
4. Browser, or browser-type element.
5. ISP-resident or network sensor.
6. Human or manual analysis.
7. Honeypot or other decoy device.
8. Other.
4.5.2. FirstSeen Element
REQUIRED. DATETIME. This is the date and time that this sensor
first saw this phishing activity.
4.5.3. Name Element
Multilingual STRING. This is the DNS name or other identifier of
the entity that generated this report.
4.5.4. Address Element
IODEF.SOURCE. This is the IPVersion, IPAddress, and optionally,
port number of the entity that generated this report.
Cain & Jevans Expires May 4, 2006 [Page 14]
Internet-Draft IODEF Fraud Report Extensions October 2005
4.5.5. Location Element
STRING. This is an optional location of the sensor.
4.6. TakeDownInfo Element
This element identifies the agency(s) that performed the removal or
ISP-blockage of the phish or fraud collector site. A PhraudReport
may have multiple TakeDownInfo elements to support activities where
multiple agencies are active. 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.
+-------------------+
| TakeDownInfo |
+-------------------+
| |<>---(0..1)--[ TakeDownDate ]
| |<>---(0..1)--[ TakeDownAgency ]
| |<>---(0..1)--[ TakeDownComments ]
+-------------------+
4.6.1. TakeDownDate Element
DATETIME. This is the date and time that takedown of the
collector site occurred.
4.6.2. TakeDownAgency Element
STRING. This is a fre eform string identifying the agency that
performed the takedown
4.6.3. TakeDownComments Element
STRING. A free form field to add any additional details of this
takedown effort.
4.7. ArchivedData Element
+-------------------+
| ArchivedData |
+-------------------+
| ENUM Type |<>---(0..1)--[ ArchivedDataURL ]
| |<>---(0..1)--[ ArchivedDataComments ]
+-------------------+
The ArchivedData element is used to typecast and include a gzip
archive file of a data collection site, base camp, or other site
where the phisher developed their code. This element will be
Cain & Jevans Expires May 4, 2006 [Page 15]
Internet-Draft IODEF Fraud Report Extensions October 2005
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 three
types of archives currently supported, as specified in the type
field.
4.7.1. Type Parameter
This parameter specifies the contents of the archive.
1. Data Collection Site.
2. Basecamp Site.
3. Sender Site.
4. Unspecified.
4.7.2. ArchivedDataURL Element
URL. This is the URL where the gzip archive file is located.
[As archives are quite large, a Fraud Report just points out
where the archive is, and does not include it in the report.]
4.7.3. ArchivedDataComments Element
STRING. This field is a free form area for comments on the
archive and/or URL.
4.8. RelatedData Element
URL. This element allows the listing of other web or net sites that
are related to this incident (e.g., victim site, etc).
4.9. CorrelationData Element
STRING. Any information that correlates this incident to other
incidents can be entered here.
4.10. PRComments Element
STRING. This field allows for any comments specific to this
PhraudReport that does not fit in any other field.
4.11. EmailRecord Element
Extensions are also made to the INCH IODEF Incident EventData element
to support descriptive information received in phishing lure or spam
emails. The ability to report spam is included within a PhraudReport
Cain & Jevans Expires May 4, 2006 [Page 16]
Internet-Draft IODEF Fraud Report Extensions October 2005
to support exchanging information about large-scale spam activities,
not necessarily a single spam message to a user. As such the spam
reporting mechanism was not designed to minimize overhead and
processing.
Information related to the overall fraudulent activity is contained
within the PhraudReport, while the EmailRecord element is used to
capture forensic or detailed technical information about a specific
attack. Incident Reports may have none, one, or multiple
EmailRecords as its goal is to accumulate pertinent technical data
associated with an specific attack as an investigation continues.
+--------------------+
| EmailRecord |
+--------------------+
| |<>-----------[ EmailCount ]
| |<>-----------[ EmailHeader ]
| |<>--(0..1)---[ EmailBody ]
| |<>--(0..1)---[ EmailComments ]
+--------------------+
4.11.1. EmailCount Element
NUMBER. This field enumerates the number of email messages
identified in this record detected by the reporter.
4.11.2. EmailHeader Element
STRING. 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 mailRecord
4.11.3. EmailBody Element
STRING. This element contains the body of the phish email. If
present, there should be at most one EmailBody element per
EmailRecord
4.11.4. EmailComments Element
STRING. This field contains comments or relevant data not placed
elsewhere about the phishing or spam email.
Cain & Jevans Expires May 4, 2006 [Page 17]
Internet-Draft IODEF Fraud Report Extensions October 2005
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. The following table identifies attributes required
to be present in a compliant PhraudReport. 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 and
PhraudReport required fields.
+--------------+
| Incident |
+--------------+
| ENUM Purpose |---[ IncidentID ]
| |---[ Assessment ]
| | ---> [ Confidence ]
| |---[ ReportTime ]
| |---[ Contact ]
| | ---> [ Role ]
| | ---> [ Type ]
| | ---> [ Name ]
| |---[ EventData ]
| | ---> [ AdditionalData]
| | ---> [ FraudReport ]
| | ---> [ FraudType ]
| | ---> [ FraudParameter ]
| | ---> [ FraudedBrandName ]
| | ---> [ LureSource ]
| | ---> [ OriginatingSensor ]
| |
+--------------+
5.1. Fraud or Phishing Report
A compliant IODEF PhraudReport is required to contain the following
fields:
Purpose
IncidentID
ReportTime
Contact -> Role
Cain & Jevans Expires May 4, 2006 [Page 18]
Internet-Draft IODEF Fraud Report Extensions October 2005
Contact -> Type
Contact -> Name
Assessment
EventData
DetectTime
AdditionalData
PhraudReport
FraudType
FraudedBrandName
LureSource
OriginatingSensor
5.2. Wide-Spread Spam Report
These following fields MUST be populated in an IODEF PHraudReport
compliant Spam Activity Report:
Incident Structure:
IncidentID
Purpose
ReportTime
Contact -> Role
Contact -> Type
Contact -> Name
Assessment
EventData
DetectTime
Cain & Jevans Expires May 4, 2006 [Page 19]
Internet-Draft IODEF Fraud Report Extensions October 2005
AdditionalData
PhraudReport
FraudType == spamreport
LureSource
OriginatingSensor
EmailRecord
EmailCount
EmailHeader
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
sensitive can be marked as such using the restriction parameter of
each data element.
Cain & Jevans Expires May 4, 2006 [Page 20]
Internet-Draft IODEF Fraud Report Extensions October 2005
6. Security Considerations
This document specifies the format of security incident data. As
such, the security of transactions containing the incident report
will vary from organization to organization. We do not want to
burden the information exchange with unnecessary encryption
requirements, as the transport service for the data exchange may
provide adequate protections, or even encryption. The use of
encryption is expected to be agreed upon on originator-recipient
agreement.
The critical security concern is that phishing activity reports may
be falsified or the report may become corrupt during transit. In
areas where transmission security or secrecy is necessary the
application of a digital signature and/or message encryption on each
report will counteract both of these concerns, The digital signature
may be overkill for most activity report users as the goal is to
notify others of the event. For this reason, phishing activity
reports MAY be digitally signed with the optional IODEF XML
signature, although we expect that each receiving entity will
determine the need for this signature independently.
Recipients of fraud reports SHALL be prepared to accept XML digitally
signed reports and SHOULD support receiving encrypted reports.
Cain & Jevans Expires May 4, 2006 [Page 21]
Internet-Draft IODEF Fraud Report Extensions October 2005
7. IANA Considerations
This document has no actions for IANA.
Cain & Jevans Expires May 4, 2006 [Page 22]
Internet-Draft IODEF Fraud Report Extensions October 2005
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.
9. Normative References
[IDMEF] Curry, D. and H. Debar, "The Intrusion Detection Message
Exchange Format", July 2004.
[IODEF] Meijer, J., Danyliw, and Demchenko, "The Incident Object
Description Exchange Format Data Model and XML
Implementation", August 2005.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
Cain & Jevans Expires May 4, 2006 [Page 23]
Internet-Draft IODEF Fraud Report Extensions October 2005
Appendix A. Phishing Extensions XML Schema
A digital copy of this file is available to prevent errors when re-
entering text. See www.coopercain.com/incidents .
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:phish="phish"
xmlns:ns="http://www.w3.org/1999/xhtml"
xmlns:iodef="draft-ietf-inch-iodef-045.xsd"
xmlns:hfp="http://www.w3.org/2001/XMLSchema-hasFacetAndProperty"
targetNamespace="phish" elementFormDefault="qualified"
attributeFormDefault="qualified">
<xs:import namespace="draft-ietf-inch-iodef-045.xsd"
schemaLocation="draft-ietf-inch-iodef-045.xsd"/
> <
!-- This Schema complies with draft-ietf-inch-phishingextns-02.txt
====================================================================
=== Top Level Class: PhraudReport ===
====================================================================
-->
<xs:element name="PhraudReport">
<xs:complexType>
<xs:sequence>
<xs:annotation>
<xs:documentation>This is an EventData.AdditionalData
structure for an IODEF Incident class.</xs:documentation>
</xs:annotation>
<xs:element name="PhishNameRef"
type="xs:string" minOccurs="0"/>
<xs:element name="PhishNameLocalRef"
type="xs:string" minOccurs="0"/>
<xs:element name="FraudParameter" minOccurs="0">
<xs:complexType mixed="true">
<xs:choice>
<xs:element name="string" type="xs:string"/>
<xs:element ref="phish:url"/>
<xs:element ref="phish:email"/>
<xs:element ref="phish:Source"/>
</xs:choice>
</xs:complexType>
</xs:element>
<xs:element name="FraudedBrandName" type="xs:string"/>
<xs:element name="LureSource">
<xs:complexType mixed="true">
<xs:sequence>
<xs:element ref="phish:Source" minOccurs="1"
maxOccurs="unbounded"/>
Cain & Jevans Expires May 4, 2006 [Page 24]
Internet-Draft IODEF Fraud Report Extensions October 2005
<xs:element name="comment" type="xs:string"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element ref="phish:OriginatingSensor"
minOccurs="1" maxOccurs="unbounded"/>
<xs:element ref="phish:EmailRecord"
minOccurs="0" maxOccurs="1"/>
<xs:element ref="phish:DCSite" minOccurs="0"
maxOccurs="unbounded"/>
<xs:element ref="phish:TakeDownInfo"
minOccurs="0" maxOccurs="unbounded"/>
<xs:element ref="phish:ArchivedData" minOccurs="0"
maxOccurs="unbounded"/>
<xs:element ref="phish:RelatedData" type="xs:string"
minOccurs="0" maxOccurs="unbounded"/>
<xs:element ref="phish:CorrelationData" type="xs:string"
minOccurs="0" maxOccurs="unbounded"/>
<xs:element name="PRComments" type="xs:string"
minOccurs="0" maxOccurs="1"/>
</xs:sequence>
<xs:attribute name="Version" use="optional" default="1"/>
<xs:attribute name="FraudType" use="required">
<xs:simpleType>
<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="unknown"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
</xs:complexType>
</xs:element>
<!--
==================================================================
=== Top Level Class: EmailRecord ===
==================================================================
-->
Cain & Jevans Expires May 4, 2006 [Page 25]
Internet-Draft IODEF Fraud Report Extensions October 2005
<xs:element name="EmailRecord">
<xs:complexType>
<xs:sequence>
<xs:element name="EmailCount" type="xs:integer"/>
<xs:element name="EmailHeader">
<!-- This is an ugly way to deal with
multi-line header info. -->
<xs:complexType>
<xs:sequence>
<xs:element name="Header" type="xs:string"
minOccurs="1" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="EmailBody" type="xs:string"
minOccurs="0" maxOccurs="1"/>
<xs:element name="EmailComments" type="xs:string"
minOccurs="0" maxOccurs="1"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<!--
==================================================================
=== Data Collection Site Info ===
==================================================================
-->
<xs:element name="DCSite">
<xs:complexType>
<xs:sequence>
<xs:element name="DCSiteData" maxOccurs="unbounded">
<xs:complexType>
<xs:choice>
<xs:element name="siteurl" type="xs:anyURI"/>
<xs:element name="emailsite" type="xs:string"/>
<xs:element ref="phish:Source" id="IPAddress"/>
<xs:element name="unknown" type="xs:string"/>
</xs:choice>
<xs:attribute name="DCSitetype" use="required">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:enumeration value="web"/>
<xs:enumeration value="email"/>
<xs:enumeration value="ipaddress"/>
<xs:enumeration value="unknown"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
Cain & Jevans Expires May 4, 2006 [Page 26]
Internet-Draft IODEF Fraud Report Extensions October 2005
</xs:complexType>
</xs:element>
</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>
</xs:element>
<!--
===================================================================
=== The Originating Sensor Data Element ===
===================================================================
-->
<xs:element name="OriginatingSensor">
<xs:complexType>
<xs:sequence>
<xs:element name="FirstSeen" type="xs:dateTime"/>
<xs:element name="name"
type="iodef:MultilingTextType" minOccurs="0"/>
<xs:element
maxOccurs="unbounded" minOccurs="1" ref="phish:Source"/>
<xs:element minOccurs="0" ref="iodef:Location"/>
</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>
</xs:element>
Cain & Jevans Expires May 4, 2006 [Page 27]
Internet-Draft IODEF Fraud Report Extensions October 2005
<xs:element name="Source">
<xs:complexType>
<xs:sequence>
<xs:element ref="phish:Protocol"/>
<xs:element name="Addr" type="xs:string"/>
<xs:element name="port" type="xs:string"
minOccurs="0"/>
<xs:element name="vlan-name" type="xs:string"
minOccurs="0"/>
<xs:element name="vlan-num" type="xs:string"
minOccurs="0"/>
<xs:element name="comment" type="xs.string"
minOccurs="0" />
</xs:sequence>
<xs:attribute ref="iodef:addrcat" use="required"/>
<xs:attribute default="unknown" ref="iodef:spoofed"/>
</xs:complexType>
</xs:element>
<xs:element name="Protocol" default="TCP">
<xs:simpleType>
<xs:restriction base="xs:NMTOKENS">
<xs:enumeration value="TCP"/>
<xs:enumeration value="UDP"/>
<xs:enumeration value="ICMP"/>
<xs:enumeration value="Other"/>
</xs:restriction>
</xs:simpleType>
</xs:element>
<!--
===================================================================
=== The Take Down Data structure. ===
===================================================================
-->
<xs:element name="TakeDownInfo">
<xs:complexType>
<xs:sequence>
<xs:element name="TakeDownDate" type="xs:dateTime"
minOccurs="0"/>
<xs:element name="TakeDownAgency" type="xs:string"
minOccurs="0" maxOccurs="unbounded"/>
<xs:element name="TakeDownComments"
type="xs:string" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
</xs:element>
Cain & Jevans Expires May 4, 2006 [Page 28]
Internet-Draft IODEF Fraud Report Extensions October 2005
<!--
===================================================================
=== The Archived Data Element ===
===================================================================
-->
<xs:element name="ArchivedData">
<xs:complexType>
<xs:sequence>
<xs:element name="ArchivedDataURL"
type="xs:anyURI" minOccurs="0"/>
<xs:element name="ArchivedDataComments"
type="xs:string" minOccurs="0"/>
</xs:sequence>
<xs:attribute name="ArchivedDataType" use="required">
<xs:simpleType>
<xs:restriction
base="xs:NMTOKENS">
<xs:enumeration value="collectionsite"/>
<xs:enumeration value="basecamp"/>
<xs:enumeration value="sendersite"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
</xs:complexType>
</xs:element>
<!--
===================================================================
=== The Related Data Element ===
===================================================================
-->
<xs:element name="RelatedData">
<xs:complexType>
<xs:sequence>
<xs:element name="URLs" type="xs:anyURI"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<!-- Elements and pieces that are used in many places.-->
<xs:element name="url" type="xs:anyURI"/>
<xs:element name="email">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:pattern value="\S@\S"/>
</xs:restriction>
</xs:simpleType>
Cain & Jevans Expires May 4, 2006 [Page 29]
Internet-Draft IODEF Fraud Report Extensions October 2005
</xs:element>
</xs:schema>
Cain & Jevans Expires May 4, 2006 [Page 30]
Internet-Draft IODEF Fraud Report Extensions October 2005
Appendix B. Examples of Complete Fraud Activity Reports
B.1. Sample Phish/Malware Email Report
B.2. Received Email
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
B.3. 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
xmlns="draft-ietf-inch-iodef-045.xsd"
xmlns:ns="http://www.w3.org/1999/xhtml"
xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
xmlns:hfp="http://www.w3.org/2001/XMLSchema-hasFacetAndProperty"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="draft-ietf-inch-iodef-045.xsd
draft-ietf-inch-iodef-045.xsd"
xmlns:iodef="draft-ietf-inch-iodef-045.xsd">
<Incident purpose="other">
<IncidentID Issuer="Pat">PAT2005-06</IncidentID>
<Description>This is a test report from actual data.
</Description>
<Contact contacttype="person" contactrole="creator">
<NameIdentifier format="emailAddress">
pcain@coopercain.com</NameIdentifier>
Cain & Jevans Expires May 4, 2006 [Page 31]
Internet-Draft IODEF Fraud Report Extensions October 2005
</Contact>
<ReportTime>2005-06-22T08:30:00-05:00</ReportTime>
<Assessment> <Confidence rating="high" />
</Assessment>
<EventData>
<DetectTime>2005-06-21T18:22:02-05:00</DetectTime>
<AdditionalData dtype="xml">
<PhraudReport FraudType="" Version="0.2" xmlns="phish">
<FraudParameter>Subject: You have successfully updated
your password</FraudParameter>
<FraudedBrandName>Cooper-Cain</FraudedBrandName>
<LureSource>
<Address iodef:addrcat="ipv4-addr"
iodef:spoofed="unknown">
<Addr>216.231.63.162</Addr>
</Address>
</LureSource>
<OriginatingSensor OriginatingSensorType="human">
<Address iodef:addrcat="ipv4-addr">
<Addr>10.0.0.4</Addr>
</Address>
</OriginatingSensor>
<EmailRecord>
<EmailCount>1</EmailCount>
<EmailHeader>
<Header>Return-path: <support@coopercain.com>
</Header>
<Header>Envelope-to: pcain@coopercain.com</Header>
<Header>Delivery-date:
Fri, 10 Jun 2005 15:52:11 -0400 </Header>
<Header>
Received: from dsl231-063-162.sea1.dsl.speakeasy.net
([216.231.63.162] helo=coopercain.com)</Header>
<Header> by mail06.coopercain.com with esmtp (Exim)
</Header>
<Header> id 1DgpXy-0002Ua-IR</Header>
<Header> for pcain@coopercain.com;
Fri, 10 Jun 2005 15:52:10-0400</Header>
<Header>From:
support@coopercain.com</Header>
<Header>To: pcain@coopercain.com</Header>
<Header>Subject: You
have successfully updated your password</Header>
<Header>Date: Fri, 10 Jun 2005 12:52:00 -0700</Header>
<Header>MIME-Version: 1.0</Header>
<Header>Content-Type: multipart/mixed;</Header>
<Header>
boundary="----=_NextPart_000_0008_0911068B.E7EB6D2A"
Cain & Jevans Expires May 4, 2006 [Page 32]
Internet-Draft IODEF Fraud Report Extensions October 2005
</Header>
<Header>X-Priority: 3</Header>
<Header>X-MSMail-Priority: Normal</Header>
<Header>X-EN-OrigIP: 216.231.63.162</Header>
<Header> X-EN-OrigHost:
dsl231-063-162.sea1.dsl.speakeasy.net </Header>
<Header>X-Spam-Checker-Version: SpamAssassin 3.0.2
(2004-11-16) on </Header> <Header>
scan18.int.bizland.net</Header>
<Header>X-Spam-Level: ***** </Header>
<Header>X-Spam-Status: No, score=5.6
required=6.0 tests=BAYES_95,CABLEDSL,HTML_20_30,
</Header>
<Header>HTML_MESSAGE,MIME_HTML_ONLY,
MISSING_MIMEOLE, NO_REAL_NAME,</Header>
<Header>PRIORITY_NO_NAME
autolearn=disabled version=3.0.2</Header>
</EmailHeader>
</EmailRecord>
</PhraudReport>
</AdditionalData>
</EventData>
</Incident>
</IODEF-Document>
Cain & Jevans Expires May 4, 2006 [Page 33]
Internet-Draft IODEF Fraud Report Extensions October 2005
Appendix C. Sample Spam Report
[ ed. To be supplied, but it looks a lot like the fraud report]
Cain & Jevans Expires May 4, 2006 [Page 34]
Internet-Draft IODEF Fraud Report Extensions October 2005
Authors' Addresses
Patrick Cain
The Cooper-Cain Group
P.O. Box 400992
Cambridge, MA
USA
Email: pcain@coopercain.com
David Jevans
The Anti-Phishing Working Group
38 Rice Street, Suites 2-0/2-2
Cambridge, MA, 02140
USA
Email: dave.jevans@antiphishing.org
Cain & Jevans Expires May 4, 2006 [Page 35]
Internet-Draft IODEF Fraud Report Extensions October 2005
Intellectual Property Statement
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.
Disclaimer of Validity
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 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.
Copyright Statement
Copyright (C) The Internet Society (2005). 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.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Cain & Jevans Expires May 4, 2006 [Page 36]