Initial Version I-D Submission Deadline Extended to March 4, 2009
The IESG has extended the deadline for initial version (00) submissions of Internet Drafts by 2 days (48 hours). The new deadline is March 4, 2009 at 1700 Pacific (March 5, 2009 at 0100 UTC / GMT) and the extension is for IETF 74 only. The deadline has been extended due to the copyright legend text alternative being recently finalized, approved and implemented. Please note that the date for updated I-D versions has NOT been extended, and is still March 9, 2009. Regards, Alexa --- Alexa Morris / Executive Director / IETF 48377 Fremont Blvd., Suite 117, Fremont, CA 94538 Phone: +1.510.492.4089 / Fax: +1.510.492.4001 Email: amor...@amsl.com Managed by Association Management Solutions (AMS) Forum Management, Meeting and Event Planning www.amsl.com http://www.amsl.com/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Comments requested on recent appeal to the IESG
I find these arguments to be unpersuasive and somewhat offensive. There is no way for any machine to ever know where one ends and the other begins. Ergo it will be possible for someone to object to any protocol on the grounds that someone might conflate Authorization and Authentication. This is inevitable because there will be occasions where the intended authorization policy for a resource is to allow through everything that is authenticated. From: Stephen Kent [mailto:k...@bbn.com] Sent: Fri 2/20/2009 2:49 PM To: Hallam-Baker, Phillip Cc: ietf@ietf.org Subject: RE: Comments requested on recent appeal to the IESG At 9:00 PM -0800 2/19/09, Hallam-Baker, Phillip wrote: Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary=_=_NextPart_001_01C99318.3582B8D8 Just as a matter of observation, there is not and never has been a security requirement to rigidly separate authentication and authorization. Indeed there is no real world deployment in which authentication and authorization are not conflated to some degree. Authentication and authorization (aka access control) are distinct security services. Too often they are confused, and the result of such confusion is never a great outcome. I have not read the doc in question, but your dismissal of this issue is not persuasive. The separation of authentication and authorization is a matter of administrative and operational convenience. nonsense. the two are implemented via a wide range of mechanisms, many of which are independent of one another. I may use passwords or challenge-response mechanisms or PKI technology for authentication, and use various identity-based authorization mechanisms with any of these means of verifying an identity. Thus there are good technical and design reasons to consider the services and mechanisms separately, as part of a modular design approach. It is very rarely the case that every privilege that might potentially be granted to a user is known in advance. Hence the benefit of maintaining a distinction. But in practice the fact that a party holds a valid authentication credential is in itself often (but not always) sufficient to make an authorization decision in low-risk situations. True, but the fact that you had to employ several qualifiers in these sentences to make them true illustrates the benefits of distinguishing between the terms. Thus an objection based on the mere risk that such a conflation may occur is not justified as such conflation has occured in every practical security system ever. I don't know if the objection is an important one here, but I do think it is important in general. We do not issue employee authentication badges to non-employees. Thus an employee-authentication badge will inevitably carry de-facto authorization for any action that is permitted to every employee (like open the office door). A good example to make my point. It is typically the case that if all employees have ID badges, these badges grant access to most buildings/rooms of the employer's facilities. But many other rooms of an employer's facilities typically are off limits to all but a few employees. The Authorization/Authentication model is in fact broken, in a modern system such as SAML you actually have three classes of data with the introduction of attributes. SAML allows one to make security assertions of all sorts. The fact that one can make both authentication and authorization assertions using the same construct is distinct from the question of whether conflating the two terms is a good idea in general, as you seem to be arguing. Steve ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-crocker-email-arch (Internet Mail Architecture) to Proposed Standard
The IESG wrote: The IESG has received a request from an individual submitter to consider the following document: - 'Internet Mail Architecture ' draft-crocker-email-arch-11.txt as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2009-03-26. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-crocker-email-arch-11.txt I've reviewed the latest version and it addresses my earlier comments I've sent to Dave Crocker privately. I think it is an important document and it is long overdue for publication. While I can see people asking for improvements forever, I think it is important to publish a snapshot ASAP. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-crocker-email-arch (Internet Mail Architecture) to Proposed Standard
The IESG wrote: The IESG has received a request from an individual submitter to consider the following document: - 'Internet Mail Architecture ' draft-crocker-email-arch-11.txt as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2009-03-26. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-crocker-email-arch-11.txt I've reviewed the latest version and it addresses my earlier comments I've sent to Dave Crocker privately. I think it is an important document and it is long overdue for publication. While I can see people asking for improvements forever, I think it is important to publish a snapshot ASAP. +1 Ned ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Some WG Mail Lists Archiving Incorrectly
On February 3rd we upgraded the Mailman list archives in order to keep spammers from sending spam directly to our archives. It has since been brought to our attention that, as side effect of this upgrade, some mail lists with previously public archives had their list configuration reset to private archiving, which means that these archives have not been available for several weeks. We are currently going through the Mailman settings for each of these lists and resetting the archives so that they will once again be publicly available. We anticipate that the list archives will be properly repaired by early next week. The complete tally of impacted lists is included below. As always, please feel free to contact me with any questions or concerns. Impacted Mail Lists: 16ng adslmib ason-routing bmwg bofchairs bridge-mib cfrg crisp dccp diffserv-interest dns-dir ecrit enum gsmp hubmib ietf-message-headers imap intersecs ipcdn ipdir ipoverib ipv6-adoption irtf-announce isis-update kmart l1vpn l2vpn l3vpn ldap-dir lemonade malloc media-feature-tags megaco midcom mip4 mip6 mipshop mobopts mpls mpls-interop nemo new-work nsis numbers ops-dir ospf-wireless-design p2pi-com pana pim port-srv-reg pppext proxies pwe3 rai-discuss rfced-ietf rip rir-ietf rmonmib rmt rohc rserpool rtg-bfd rtg-dir rtg-mibs rtg-rdd rtgwg saad sigtran sitescope-list spam-discussion speechsc ssm tcpao-security tmc tsv-dir uri-review urn-nid videomgmt vpim vpn-dir vrrp w3c-policy xcon Regards, Alexa --- Alexa Morris / Executive Director / IETF 48377 Fremont Blvd., Suite 117, Fremont, CA 94538 Phone: +1.510.492.4089 / Fax: +1.510.492.4001 Email: amor...@amsl.com Managed by Association Management Solutions (AMS) Forum Management, Meeting and Event Planning www.amsl.com http://www.amsl.com/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Some WG Mail Lists Archiving Incorrectly
One thing that I did not make clear in my original email is that our preliminary investigation indicates that no mail has been lost, it has just been moved to private archives. Therefore we anticipate that all mail will be restored in the appropriate public archive early next week. Alexa On Feb 26, 2009, at 4:11 PM, Alexa Morris wrote: On February 3rd we upgraded the Mailman list archives in order to keep spammers from sending spam directly to our archives. It has since been brought to our attention that, as side effect of this upgrade, some mail lists with previously public archives had their list configuration reset to private archiving, which means that these archives have not been available for several weeks. We are currently going through the Mailman settings for each of these lists and resetting the archives so that they will once again be publicly available. We anticipate that the list archives will be properly repaired by early next week. The complete tally of impacted lists is included below. As always, please feel free to contact me with any questions or concerns. Impacted Mail Lists: 16ng adslmib ason-routing bmwg bofchairs bridge-mib cfrg crisp dccp diffserv-interest dns-dir ecrit enum gsmp hubmib ietf-message-headers imap intersecs ipcdn ipdir ipoverib ipv6-adoption irtf-announce isis-update kmart l1vpn l2vpn l3vpn ldap-dir lemonade malloc media-feature-tags megaco midcom mip4 mip6 mipshop mobopts mpls mpls-interop nemo new-work nsis numbers ops-dir ospf-wireless-design p2pi-com pana pim port-srv-reg pppext proxies pwe3 rai-discuss rfced-ietf rip rir-ietf rmonmib rmt rohc rserpool rtg-bfd rtg-dir rtg-mibs rtg-rdd rtgwg saad sigtran sitescope-list spam-discussion speechsc ssm tcpao-security tmc tsv-dir uri-review urn-nid videomgmt vpim vpn-dir vrrp w3c-policy xcon Regards, Alexa --- Alexa Morris / Executive Director / IETF 48377 Fremont Blvd., Suite 117, Fremont, CA 94538 Phone: +1.510.492.4089 / Fax: +1.510.492.4001 Email: amor...@amsl.com Managed by Association Management Solutions (AMS) Forum Management, Meeting and Event Planning www.amsl.com http://www.amsl.com/ --- Alexa Morris / Executive Director / IETF 48377 Fremont Blvd., Suite 117, Fremont, CA 94538 Phone: +1.510.492.4089 / Fax: +1.510.492.4001 Email: amor...@amsl.com Managed by Association Management Solutions (AMS) Forum Management, Meeting and Event Planning www.amsl.com http://www.amsl.com/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Comments requested on recent appeal to the IESG
On Feb 26, 2009, at 10:47 AM, Alessandro Vesely wrote: Douglas Otis wrote: 3) Separate SMTP clients share the same IP addresses. (Unfortunately this is also a common practice. Brazil, Poland, and other places have many ISPs that expect hundreds or thousands of customers to run outbound SMTP services that NAT to a single or small number of IP addresses. It is also common for VPS services to run servers out of common IP addresses.) The domain that operates the NAT is responsible for letting their users connect to port 25. Operating through a NAT may disrupt an inner site's activity, if some of its co-NAT sites behave badly. Again, recipients can mark this weak authentication characteristic by domain name. Alessandro, Tens of thousands of domains might use the same NATed addresses offered by a network carrier. For authorization mechanisms, if the SMTP client IP address was included within the Authentication-Results header, then messages emerging from known NATed addresses could be easily identified, and appropriately they would not receive annotations as having originated from an authorizing domain. The proactive protections afforded by inclusion of the SMTP client IP address would be substantial. There are hundreds of thousands of legitimate SMTP clients in comparison to hundreds of millions of domains. This sizable difference makes SMTP client based annotation assessment a thousand of times more comprehensive. It is already very difficult to detect spear phishing events. Basing assessments only upon events evidenced by the domain, rather than by the SMTP client IP address, means this insidious activity is more likely to go on unabated. 4) Authorization results that are based upon a virtual record when no SPF record is found. (Injecting SPF mx/24 record mechanisms whenever no SPF is discovered is also a common practice.) That's totally bogus. I may accept a bug in my ISP's SPF checking software, but deliberately falsifying the data requires that trusted-isp.com be removed from my set of trustees. Customers of such providers will still desire their email to be annotated. They will be asked to enter the name of their provider into the MUA while being unaware of any underlying SPF record guesswork. Allowing the MUA a means to check the status of the SMTP client reduces risks created by authorization guesswork or a provider's acceptance requirements. Judging whether to annotate is a much different decision from deciding whether to accept a message. ... It can only be said that a domain *authorized* the SMTP client. Yes, the client is authorized to say it sends on behalf of that domain: it is a user of that domain by definition. This statement is not correct. This is why it is so wrong to confuse *authorization* with *authentication*. A package delivered by Fred bearing Sam's return address where Sam references Fred as being *authorized* does not represent an assurance that the package is really from Sam. Only when Fred has a reputation of always checking sender identities against return addresses can there be any assurance that the return address is valid. In addition, an authorization of Fred by Sam should not be considered a guarantee that Fred always checks sender identities against the return addresses. An authorization only means packages delivered by unauthorized carriers should be considered suspect. This philosophy is often the basis for publishing SPF records when dealing with back- scatter. The reputation most relevant as to whether a return address might be valid is that of the carrier Fred. ... I doubt that displaying 192.0@example.com will make the recipient safer. The alternative might be h...@example.com is used with a message asking you to complete your W2 form at a specific web-site. Unfortunately, the MUA is unable to check whether 192.0.2.3 has a recent history of spoofing domains. Employees of example.com may be unaware of the limitations imposed by their outsourced email service, or may have created records intended to help ensure message delivery. Bad actors can now leverage any righteous assumptions that border MTAs might make to produce extremely convincing socially engineered attacks. See items 1- 6. These attacks are made easier whenever *authorization* is erroneously elevated into being considered *authentication* without adequate safeguards being provided. Safeguards based only upon a domain will not isolate the services culpable for domain spoofing and will inhibit an effective response to SMTP client exploits. With the possible exception of some guys of the IT department, I think no employee of example.com can tell if 192.0.2.3 is or is not the IP address of their ESP. Per the draft, the MUA is expected to check the reputation of the authenticated origin identity (this would be the SMTP client IP
Re: Withdraw of [rt.amsl.com #13277]: Authentication-Results Header Field Appeal
On Feb 25, 2009, at 11:42 PM, Murray S. Kucherawy wrote: Doug, On Wed, 25 Feb 2009 00:10:21 -0800, Doug Otis wrote: The Sender-Header-Auth draft clouds what should be clear and concise concepts. Organizations like Google have already remedied many of the security concerns through inclusion of free form comments. For the sake of being thorough, I looked into this. A lead mail engineer at Gmail (I assume you're referencing Gmail and not Google's internal mail) tells me their inclusion of the relaying IP address as a comment in their Authentication-Results header fields has nothing to do with any sort of remedy in reference to any concerns they have about the specification. It is for use by some other internal processes (which he was not at liberty to discuss further). This overlooks their claim that SMTP client IP address information is useful, even for undisclosed reasons. Even as a comment, it confirms IP addresses found elsewhere using regex as a remedy for defeating spoofed headers holding bogus IP addresses. Since you cited a plurality, do you have any other specific examples? Unfortunately other major DKIM provider Yahoo! does not offer this feature. Is your question seems aimed at ensuring the ESP wagons are fully circled? The draft omits information that is essential for checking whether a message source represents that of a NAT, for example. This is not about whether to accept a message, which might be where the reputation of the domain would matters, this is about determining whether the *authorized* client is known to protect message elements used to reference the authorizations. The Authentication-Results header is not about which messages are to be rejected, this header is about what results are safe to annotate. -Doug ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-crocker-email-arch (Internet Mail Architecture) to Proposed Standard
Tony Hansen wrote: Should it be using RFC5321/RFC5322 instead of RFC2821/RFC2822, such as RFC5322.From instead of RFC2822.From? yes. current draft came out just before the latest RFCs were published. final publication will be revised (and nits fixed -- thanks for the close read.) d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Last Call: draft-ietf-lemonade-notifications (Lemonade Notifications Architecture) to Informational RFC
The IESG has received a request from the Enhancements to Internet email to Support Diverse Service Environments WG (lemonade) to consider the following document: - 'Lemonade Notifications Architecture ' draft-ietf-lemonade-notifications-10.txt as an Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2009-03-12. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-lemonade-notifications-10.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_iddTag=14182rfc_flag=0 The following IPR Declarations may be related to this I-D: ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Initial Version I-D Submission Deadline Extended to March 4, 2009
The IESG has extended the deadline for initial version (00) submissions of Internet Drafts by 2 days (48 hours). The new deadline is March 4, 2009 at 1700 Pacific (March 5, 2009 at 0100 UTC / GMT) and the extension is for IETF 74 only. The deadline has been extended due to the copyright legend text alternative being recently finalized, approved and implemented. Please note that the date for updated I-D versions has NOT been extended, and is still March 9, 2009. Regards, Alexa --- Alexa Morris / Executive Director / IETF 48377 Fremont Blvd., Suite 117, Fremont, CA 94538 Phone: +1.510.492.4089 / Fax: +1.510.492.4001 Email: amor...@amsl.com Managed by Association Management Solutions (AMS) Forum Management, Meeting and Event Planning www.amsl.com http://www.amsl.com/ ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
