Internet Engineering Task Force J. Macdonald Internet-Draft e-Dialog Intended status: Informational D. Crocker Expires: July 31, 2009 Brandenburg InternetWorking January 27, 2009 Affiliations List (AffiL) macdonald-affiliated-nameslist-00-04dc (pre-release) Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and 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 July 31, 2009. Copyright Notice Copyright (c) 2009 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. Abstract Domain names can be used as the core identifier in an assessment Macdonald & Crocker Expires July 31, 2009 [Page 1] Internet-Draft Affiliations List (AffiL) January 2009 process, such as when filtering incoming email. One type of assessment is to note that the name is used by a person, role or organization having a particular affiliation, such as being part of a well-known company or being part of a salient industry association. Such a list is distinct from qualitative assessment lists, such as for email reputation. This specification provides a method for determining whether an individual, authenticated domain name has a particular affiliation. It provides a means by which the list owner can describe the list, but the specification does not indicate what affiliations exist or should be consulted. The specification uses Vouch By Reference (VBR) as its query mechanism. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Affiliations List Model . . . . . . . . . . . . . . . . . . . 4 3. AffiL List Description . . . . . . . . . . . . . . . . . . . . 5 3.1. List Description Syntax: . . . . . . . . . . . . . . . . . 6 3.2. List Description Location . . . . . . . . . . . . . . . . 6 4. Query Name Selection . . . . . . . . . . . . . . . . . . . . . 6 5. Consulting a List . . . . . . . . . . . . . . . . . . . . . . 7 6. Using a List Entry . . . . . . . . . . . . . . . . . . . . . . 7 7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 7.1. Member of an Industry Organization . . . . . . . . . . . . 7 7.2. Domains Owned by Publisher . . . . . . . . . . . . . . . . 8 7.3. Authorized Agents of the Email Author's Domain . . . . . . 9 8. Security Considerations . . . . . . . . . . . . . . . . . . . 11 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 9.1. Normative References . . . . . . . . . . . . . . . . . . . 11 9.2. Informative References . . . . . . . . . . . . . . . . . . 11 Appendix A. IANA Considerations . . . . . . . . . . . . . . . . . 11 A.1. AffiL Type of List Registration Details . . . . . . . . . 11 Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 Macdonald & Crocker Expires July 31, 2009 [Page 2] Internet-Draft Affiliations List (AffiL) January 2009 1. Introduction Organizations are often referenced on the Internet in terms of their registered domain names. It can be helpful to determine whether a particular name is affiliated with a particular organization or, in turn, whether a particular organization itself has an "interesting" affiliation with some other organization, group or activity. The ability to discern these affiliations can provide useful input to an assessment process, such as for filtering inbound email. Affiliation is distinct from reputation, in that it is an objective statement about a relationship, rather than a more subjective statement about quality. Typically, an affiliation list merely documents an existing relationship, whereas quality assessment statements are the result of incremental and subjective work by the publisher. Hence, affiliations are more easily documented. In terms of using the publication information for performing decision-making by the consumer, the utility of an affiliations list is based on having the consumer of the list perform the quality assessment step, rather than the publisher. Many different types of affiliation lists are possible. They can declare ownership by the publisher, some sort of permission by the publisher, membership in a group, and so on. Examples include: o An an industry organization such as one for financial institutions or airlines might wish to publish a list of its members. o A single organization might control many domain names that appear to be unrelated and might be scattered across several branches of the domain name hierarchy. o An organization that authors mail, and has its domain name in the RFC5321.From field, might wish to provide an explicit list of the organizations that are authorized to send mail on its behalf and with its domain name in the From: field. This specification defines a method by which organizations can publish these affiliations in an online list, so as to permit easy verification. The means by which a potential user of a list learns of its existence and then decides to query it is outside the scope of this specification. It is a distributed, open process, much like discovering and deciding to use email addresses or web addresses. Conventions used in this specification are defined by: Macdonald & Crocker Expires July 31, 2009 [Page 3] Internet-Draft Affiliations List (AffiL) January 2009 Terminology: Terminology conforms to [I-D.email-arch]. Formal Notation: Formal syntax definitions use ABNF [RFC2434]. Inline references to ABNF rules are distinguished by surrounding <...> brackets. References to formally-defined commands or fields are marked by a two-part notation, first listing the specification and then listing the command or field, in the form: specification.command-field. As a shorthand, references to fields within the RFC5322 header use a Fieldname: notation. Normative Language: The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. DISCUSSION: Public discussion of this draft should be conducted on the affil-discuss@mipassoc.org mailing list. NOTE TO RFC EDITOR: This "Discussion" text is to be removed prior to publication. 2. Affiliations List Model A list declares affiliation for a set of names, that is, association to the group or activity for which the list is published. It carries no additional semantics beyond the claim of membership. For example it does not suggest that a member of the list is a Good Actor or a Bad Actor in their email interactions with the consumer of the list. Lists can be self-published, by the owner of the listed names -- self-listed publication -- or by a different organization -- independent publication. The list is published by the list owner, so that presence on the list is self-authenticating and self-certifying. The list owner separately publishes an Affiliation Description which specifies the list's criteria for membership and provides any details for attributes encoded into a list entry. A list is accessible via a domain name that is called the List Name. The owner of that domain name is called the List Owner. The decision to consult a particular list is made in two stages. The first stage occurs long before the list is consulted and is performed as an administrative act. It is a strategic, deliberative activity that decides what lists are to be enabled for consultation. Macdonald & Crocker Expires July 31, 2009 [Page 4] Internet-Draft Affiliations List (AffiL) January 2009 NOTE: List publishers need to carefully consider the value proposition and usage cost for the list, as they will be assessed by potential queriers, since these are likely to be the primary factors in their deciding whether to enable list consultation. A challenging aspect of this exercise, for list publishers, is to assume that there will be many such lists, produced by many publishers, and that the aggregate cost of consulting many lists is expensive. Hence the value-proposition for a particular list needs to be distinctive. The second stage occurs as part of regular, in-line operations, at the time lists are consulted. It is determined by immediate details of operation, such as the content or attributes of a received email. When a list is queried, the primary result MUST be a binary statement of list membership: Is the queried domain in the queried list? The query MAY also produce related, parametric information about the queried domain. AffiL uses Vouch By Reference (VBR) [I-D.VBR] as its query mechanism. As currently specified, VBR is defined for use by independent parties to certify a set of domain name owners that are associated with received mail. However, the mechanism equally can support publication by the owner of listed names. That is, it permits an organization to self-list a set of domain names. AffiL treats the cases of Self-Listing and Independent Listing as equivalent and the differences between the two are outside the cope of AffiL, but of course can be an important factor in a potential querier's decision about whether to consult a particular list. 3. AffiL List Description Prior to consulting a particular list, a potential querier decides that this list is (sometimes) worthy of consultation. They decide to configure their run-time software to include the list for queries under specified conditions that the querier can envision. There are many different ways by which a potential querier might learn about the existence of a list and the details for it. To assist such discovery efforts, the publisher MAY provide a web page that describes the list and specifies any special syntax and semantics for it. This section defines a standard format for such a description of an Affiliations List. A list description comprises: Macdonald & Crocker Expires July 31, 2009 [Page 5] Internet-Draft Affiliations List (AffiL) January 2009 Domain Name of list: This specifies the location in the DNS at which the list can be found. Descriptive Name of List: This provides a human-friendly label for referencing the list Type of List: In order to facilitate a queriers' consideration of what lists to use, this provides a registered label that describes the common semantics of the list. {{ IANA Registration required }} Revision date for list description: This supports basic version control. Name of person, role, brand or organization publishing the list: This provides the human-friendly common label for the list owner. Textual description of the list: This is a free-form explanation of the nature and purpose for this list. One or more list entries, comprising: + Domain name + Name of affiliated organization + List-specific attributes, such as type of membership, duration of membership, security policies for organization. 3.1. List Description Syntax: ABNF TBD 3.2. List Description Location (Where is a List Description located?) TBD 4. Query Name Selection Content, such as email, typically contains many name references. Any of these might be a candidate as the name to use for an AffiL query. The choice is determined by the semantics of the list to be queried. Macdonald & Crocker Expires July 31, 2009 [Page 6] Internet-Draft Affiliations List (AffiL) January 2009 If the VBR-Info tag is present, the md= can suggest the choice; other tags within the header field can indicate further query constraints. 5. Consulting a List A module that is performing assessments is likely to have a range of lists available for consulting. The first task, then, is to decide which to query. The factors that determine the choices will vary. For email, the presence of specific identifiers or specific types of identifiers will be important. For example, the rfc5322.From field might contain a well-known domain name that is often spoofed, or a validated identifier for message responsibility might need to be assessed. As input to the decision process the data being evaluated MAY itself offer hints. For example, VBR is tailored for use with email and permits a message to contain a VBR-Info: header field. The field contains advice from the message creator. This advice is only a suggestion about lists to consult and MUST NOT be taken as confirming the affiliation that is claimed. That is, it can only be used as a hint by a possible list member about which lists should be consulted. Validation of affiliation can only be obtained by performing the query and queries SHOULD only be made of lists already vetted by the querier. 6. Using a List Entry The primary semantic result of an AffiL query is a binary assessment about affiliation with a particular list. This assessment is then communicated to an external modules, such as an email Handling Filter that determines whether to deliver a message. 7. Examples 7.1. Member of an Industry Organization The mere fact that a person or organization is a member of a particular group can sometimes be useful in making an assessment. For example, if a message purports to be from a bank, evaluating that claim can benefit from being able to determine whether any domain names that it cites do, indeed, belong to a bank. One indication of status for the organization owning the cited domain name would be membership in a banking association. This scenario in that the list owner is independent of the domain Macdonald & Crocker Expires July 31, 2009 [Page 7] Internet-Draft Affiliations List (AffiL) January 2009 name owner(s), except for the relationship asserted through publication of the list. List Description: Domain Name of list: members.bankassoc.example Descriptive Name of List: List of the Banking Association Member Organizations Type of List: Member Revision date for list description: 22 Jan 2009 Name of person, role, brand or organization publishing the list: The Banking Association Textual description of the list: The Banking Association preserves and promotes public confidence in the financial system by insuring deposits in banks and thrift institutions. This list specifies domain names used formally by banks that have membership in The Banking Association. One or more list entries, comprising: + Domain name + Official name of member bank + List-specific attributes: None For example: + local-bank.example + The Local Bank 7.2. Domains Owned by Publisher A company, conglomerate.example, sells many different products, under many different brand names. Some of these brands are spoofed, including by the use of look-alike domain names. The company wishes to list the set of domain names that actually are affiliated with conglomerate.example. One use of this would be for an anti-abuse filtering engine to detect when a message as purports to be from the company. Consulting the conglomerate.example list could determine Macdonald & Crocker Expires July 31, 2009 [Page 8] Internet-Draft Affiliations List (AffiL) January 2009 whether the validated domain name(s) being used with the message are, in fact, used by the company This example is distinctive in that the list owner is the same as the owner of the listed domain names. List Description: Domain Name of list: conglomerate.example Descriptive Name of List: Domain names for different brands belonging to The Conglomerate Company. Type of List: Ownership Revision date for list description: 22 Jan 2009 Name of person, role, brand or organization publishing the list: The Conglomerate Company Textual description of the list: Each of the listed domain names is owned by The Conglomerate Company and is used to differentiate among different product and service brands used by the company. One or more list entries, comprising: + Domain name + Name of our brand + List-specific attributes: None For example: + branda.com + The Conglomerate Company, Brand-A 7.3. Authorized Agents of the Email Author's Domain Organizations often outsourced their email processing, such as for sending large blocks of subscription-based email to customers. Such an Email Service Provider (ESP) is an authorized agent of the organization. However the ESP's own domain names have no obvious relationship to the authorizing organization. For some scenarios, it Macdonald & Crocker Expires July 31, 2009 [Page 9] Internet-Draft Affiliations List (AffiL) January 2009 is decided to have authenticated domain names that are associated with messages be those of the ESP. The desire, then, is to permit the authorizing organization to declare that the ESP is an authorized agent for sending messages on behalf of the organization. This scenario can appear to be similar to a membership listing. However it is distinctive in that the list owner is indicated through the content of the message -- notably including the author identifier, such as the From: field. Further, by virtue of declaring that the listed domains are acting as agents of the list owner, its semantics indicate an explicit degree of trust that the list owner is declaring for the listed domains. List Description: Domain Name of list: authorizingco.example Descriptive Name of List: Authorized Email Agent Names Type of List: Delegation Revision date for list description: 22 Jan 2009 Name of person, role, brand or organization publishing the list: The Authorizing Company Textual description of the list: This list declares domain names for organizations that are authorized to send mail on behalf of The Authorizing Company. One or more list entries, comprising: + domain name + Name of authorized company + List-specific attributes: none For example: + authorizingco.esp.example + The ESP Company Macdonald & Crocker Expires July 31, 2009 [Page 10] Internet-Draft Affiliations List (AffiL) January 2009 8. Security Considerations ***** All drafts are required to have a security considerations section. ***** 9. References 9.1. Normative References [I-D.VBR] Hoffman, P., Levine, K., and A. Hathcock, "Vouch By Reference (VBR)", ID draft-hoffman-dac-vbr, December 2008. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", RFC 2434, October 1998. 9.2. Informative References [I-D.email-arch] Crocker, D., "Internet Mail Architecture", Feb 2008. Appendix A. IANA Considerations A.1. AffiL Type of List Registration Details *** Procedures for registering a "type of list" label *** Appendix B. Acknowledgements *** Acknowledgements *** Macdonald & Crocker Expires July 31, 2009 [Page 11] Internet-Draft Affiliations List (AffiL) January 2009 Authors' Addresses Jeff Macdonald e-Dialog 131 Hartwell Avenue Lexington, MA 01432 USA Phone: 781-372-1922 Email: jmacdonald@e-dialog.com Dave Crocker Brandenburg InternetWorking 675 Spruce Dr. Sunnyvale, CA 94086 USA Email: dcrocker@bbiw.net Macdonald & Crocker Expires July 31, 2009 [Page 12]