< draft-ietf-repute-model-06.txt   draft-ietf-repute-model-07.txt >
REPUTE Working Group N. Borenstein REPUTE Working Group N. Borenstein
Internet-Draft Mimecast Internet-Draft Mimecast
Intended status: Informational M. Kucherawy Intended status: Informational M. Kucherawy
Expires: January 4, 2014 Expires: January 13, 2014
A. Sullivan, Ed. A. Sullivan, Ed.
Dyn, Inc. Dyn, Inc.
July 3, 2013 July 12, 2013
A Model for Reputation Reporting A Model for Reputation Reporting
draft-ietf-repute-model-06 draft-ietf-repute-model-07
Abstract Abstract
This document describes a general architecture for a reputation-based This document describes a general architecture for a reputation-based
service and a model for requesting reputation-related data over the service and a model for requesting reputation-related data over the
Internet, where "reputation" refers to predictions or expectations Internet, where "reputation" refers to predictions or expectations
about an entity or an identifier such as a domain name. The document about an entity or an identifier such as a domain name. The document
roughly follows the recommendations of RFC4101 for describing a roughly follows the recommendations of RFC4101 for describing a
protocol model. protocol model.
skipping to change at page 1, line 38 skipping to change at page 1, line 38
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 4, 2014. This Internet-Draft will expire on January 13, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 14 skipping to change at page 2, line 14
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. High-Level Architecture . . . . . . . . . . . . . . . . . . . 5 3. High-Level Architecture . . . . . . . . . . . . . . . . . . . 5
4. Terminology and Definitions . . . . . . . . . . . . . . . . . 8 4. Terminology and Definitions . . . . . . . . . . . . . . . . . 7
4.1. Response Set . . . . . . . . . . . . . . . . . . . . . . . 8 4.1. Response Set . . . . . . . . . . . . . . . . . . . . . . . 7
4.2. Reputon . . . . . . . . . . . . . . . . . . . . . . . . . 9 4.2. Reputon . . . . . . . . . . . . . . . . . . . . . . . . . 8
5. Information Represented in a Response Set . . . . . . . . . . 9 5. Information Represented in a Response Set . . . . . . . . . . 8
6. Information Flow in the Reputation Query Protocol . . . . . . 9 6. Information Flow in the Reputation Query Protocol . . . . . . 8
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
8. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 10 8. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 9
8.1. Data In Transit . . . . . . . . . . . . . . . . . . . . . 10 8.1. Data In Transit . . . . . . . . . . . . . . . . . . . . . 9
8.2. Collection Of Data . . . . . . . . . . . . . . . . . . . . 10 8.2. Collection Of Data . . . . . . . . . . . . . . . . . . . . 9
9. Security Considerations . . . . . . . . . . . . . . . . . . . 10 9. Security Considerations . . . . . . . . . . . . . . . . . . . 9
9.1. Biased Reputation Agents . . . . . . . . . . . . . . . . . 11 9.1. Biased Reputation Agents . . . . . . . . . . . . . . . . . 10
9.2. Malformed Messages . . . . . . . . . . . . . . . . . . . . 11 9.2. Malformed Messages . . . . . . . . . . . . . . . . . . . . 10
9.3. Further Discussion . . . . . . . . . . . . . . . . . . . . 11 9.3. Further Discussion . . . . . . . . . . . . . . . . . . . . 10
10. Informative References . . . . . . . . . . . . . . . . . . . . 11 10. Informative References . . . . . . . . . . . . . . . . . . . . 10
Appendix A. Public Discussion . . . . . . . . . . . . . . . . . . 12 Appendix A. Public Discussion . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction 1. Introduction
Historically, many Internet protocols have operated between Historically, many Internet protocols have operated between
unauthenticated entities. For example, an email message's author unauthenticated entities. For example, an email message's author
field (From) [MAIL] can contain any display name or address and is field (From) [MAIL] can contain any display name or address and is
not verified by the recipient or other agents along the delivery not verified by the recipient or other agents along the delivery
path. Similarly, a sending email server using [SMTP] trusts that the path. Similarly, a sending email server using [SMTP] trusts that the
[DNS] has led it to the intended receiving server. Both kinds of [DNS] has led it to the intended receiving server. Both kinds of
trust are easily betrayed, opening the operation to subversion of trust are easily betrayed, opening the operation to subversion of
skipping to change at page 4, line 50 skipping to change at page 4, line 50
authentication details, and the like. authentication details, and the like.
Upon receipt of some content the client operator wishes to evaluate Upon receipt of some content the client operator wishes to evaluate
(an Internet message, for example), the client extracts from the (an Internet message, for example), the client extracts from the
content one or more identifiers of interest to be evaluated. content one or more identifiers of interest to be evaluated.
Examples of this include the domain name found in the From: field of Examples of this include the domain name found in the From: field of
a message, or the domain name extracted from a valid DomainKeys a message, or the domain name extracted from a valid DomainKeys
Identified Mail (DKIM) signature. Identified Mail (DKIM) signature.
Next, the goal is to ask the reputation service provider what the Next, the goal is to ask the reputation service provider what the
reputation of the extracted identifier is. This is a two-stage reputation of the extracted identifier is. The query will contain
query. The first query is to the reputation service provider at a the identifier to be evaluated and possibly some context-specific
well-known resource location to download a template. The template is information (such as to establish the context of the query, e.g., an
a string into which various parameters about the query, including the email message) or client-specific information. The client typically
identifier to be evaluated, are substituted. The result is a second folds the data in the response into whatever local evaluation logic
resource location, and a query to this location is the actual it applies to decide what disposition the content deserves.
reputation request.
The client then issues a query to the second location to request the
reputation score associated with the extracted identifier. The
client typically folds this information into whatever local
evaluation logic it applies to decide what disposition the content
deserves.
3. High-Level Architecture 3. High-Level Architecture
A reputation mechanism functions as a component of an overall A reputation mechanism functions as a component of an overall
service. A current example is that of an email system that uses service. A current example is that of an email system that uses
DomainKeys Identified Mail (DKIM; see [DKIM]) to affix a stable DomainKeys Identified Mail (DKIM; see [DKIM]) to affix a stable
identifier to a message and then uses that as a basis for evaluation: identifier to a message and then uses that as a basis for evaluation:
+-------------+ +------------+ +-------------+ +------------+
| Author | | Recipient | | Author | | Recipient |
 End of changes. 6 change blocks. 
33 lines changed or deleted 26 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/