Extensions to the IODEF-Document Class for Reporting Phishing
RFC 5901
| Document | Type |
RFC - Proposed Standard
(July 2010; No errata)
Was draft-cain-post-inch-phishingextns (individual in sec area)
|
|
|---|---|---|---|
| Last updated | 2015-10-14 | ||
| Stream | IETF | ||
| Formats | plain text pdf htmlized bibtex | ||
| Reviews | |||
| Stream | WG state | (None) | |
| Document shepherd | No shepherd assigned | ||
| IESG | IESG state | RFC 5901 (Proposed Standard) | |
| Consensus Boilerplate | Unknown | ||
| Telechat date | |||
| Responsible AD | Tim Polk | ||
| Send notices to | (None) | ||
Internet Engineering Task Force (IETF) P. Cain
Request for Comments: 5901 The Cooper-Cain Group, Inc.
Category: Standards Track D. Jevans
ISSN: 2070-1721 The Anti-Phishing Working Group
July 2010
Extensions to the IODEF-Document Class for Reporting Phishing
Abstract
This document extends the Incident Object Description Exchange Format
(IODEF) defined in RFC 5070 to support the reporting of phishing
events, which is a particular type of fraud. These extensions are
flexible enough to support information gleaned from activities
throughout the entire electronic fraud cycle -- from receipt of the
phishing lure to the disablement of the collection site. Both simple
reporting and complete forensic reporting are possible, as is
consolidating multiple incidents.
Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc5901.
Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Cain & Jevans Standards Track [Page 1]
RFC 5901 IODEF Phishing Extensions July 2010
Table of Contents
1. Introduction ....................................................3
1.1. Why a Common Report Format Is Needed .......................3
1.2. Processing of Exchanged Data Not Defined ...................4
1.3. Relation to the INCH IODEF Data Model ......................4
2. Terminology Used in This Document ...............................4
2.1. Requirements Language ......................................5
3. Interesting Fraud Event Data ....................................5
3.1. The Elements of a Phishing/Fraud Event .....................6
3.2. Useful Data Items in a Fraud Event .........................7
4. Fraud Activity Reporting via IODEF-Documents ....................8
4.1. Fraud Report Types .........................................8
4.2. Fraud Report XML Representation ............................9
4.3. Syntactical Correctness of Fraud Activity Reports ..........9
5. PhraudReport Element Definitions ...............................10
5.1. PhraudReport Structure ....................................10
5.2. Reuse of IODEF-Defined Elements ...........................11
5.3. Element and Attribute Specification Format ................11
5.4. Version Attribute .........................................12
5.5. FraudType Attribute .......................................12
5.6. PhishNameRef Element ......................................13
5.7. PhishNameLocalRef Element .................................13
5.8. FraudedBrandName Element ..................................13
5.9. LureSource Element ........................................14
5.10. OriginatingSensor Element ................................22
5.11. The DCSite Element .......................................23
5.12. TakeDownInfo Element .....................................25
5.13. ArchivedData Element .....................................27
5.14. RelatedData Element ......................................28
5.15. CorrelationData Element ..................................28
5.16. PRComments Element .......................................28
5.17. EmailRecord Element ......................................28
6. Mandatory IODEF and PhraudReport Elements ......................29
6.1. Guidance on Usage .........................................30
7. Security Considerations ........................................31
7.1. Transport-Specific Concerns ...............................31
7.2. Using the iodef:restriction Attribute .....................31
Show full document text