Re: Security Assessment of the Transmission Control Protocol (TCP)
2009/2/14 Lars Eggert lars.egg...@nokia.com
> during the discussions around the TCP implementation deficiencies
> publicized by the Outpost24 last fall, we discussed with CERT-FI and others
> in that community that the IETF would offer to be the venue for publishing
> such a document.
>
It has always been in our mind to bring the results of our project
("Security Assessment of the Transmission Control Protocol (TCP)" to the
IETF.
We have already done this for another document ("Security Assessment of the
Internet Protocol") that was part of the same project. In July 2008, the UK
CPNI released that document, and the next week after the release we publish
an IETF I-D version of the same document.
We have done the same thing with this new TCP document. I have already
submitted an IETF I-D version of the document, in the hope that the IETF
will work on this stuff. The document is entitled "Security Assessment of
the Transmission Control Protocol (TCP)", and the filename is
draft-gont-tcp-security-00.txt.
> The goal would be to document techniques that stack vendors are employing
> to harden their stacks.
>
This is sort of what we have done. However, not only have we documented
techniques that stack vendors have implemented to harden their stack, but
have also performed an assessment of the IETF specs themselves, and have
also proposed mitigation techniques for known issues (on which there had
never been advise on how to deal with them). We had a preliminar version of
our paper sometime in 2006, but then it went through a throrough review
process. That's why it ended up being published this
month.
> They asked us to wait until vendors had a chance to deploy patches to the
> latest round of vulnerabilities, and we haven't heard back from them since
> late last year. (Which reminds me to shoot them an email.)
>
I have been in the loop (for some time, at least), and have also been in
very close contact with a number of vendors. For instance, an excerpt of our
large TCP document (that discussed the specific issues that had been
publicized by Outpost24) was made available to vendors in the hope of
providing vendors with advice on how to deal with those issues.
I don't really know how the "patching" work is going on... but at least a
few months ago, I would say that many (most?) vendors were not really
working in patches. And to some extent it might make sense, as some of the
issues have more to do with having the applications controlling the amount
of resources that they are using, than with TCP trying to limit the amount
of resources per app at the TCP level.
> I believe such a document would be fully in scope for TCPM,
>
I believe both tcpm and opsec could be possible candidates for this
document.
> but obviously the involvement of the stack vendors is critical to ensure
> this is a document that has practical relevance.
>
To the extent that was possible, vendors *have* been involved in the review
process of our TCP security document. However, at times it gets hard to get
vendors involved in the IETF process. For the most part, they feel they are
not heard, and that participating in the IETF has a low ROI (Return Of
Investment).
We have had some experience in this arena with the document "ICMP attacks
against TCP" that we are still pursuing within tcpm. I was able to get
involved from the following "vendors":
* NetBSD
* OpenBSD
* FreeBSD
* Linux
* Cisco
* Sun
* HP
* ExtremeNetworks (IIRC)
* ... and others
but we nitpicked on the document for ages. Virtually everybody in the vendor
community couldn't believe that we were having such discussions about that
stuff. So at some point most people argued that "they had already voiced
their opinion, but they felt that it didn't made a difference". After all,
they had already implemented the stuff discussed in the document (and so had
others), so they really didn't have much of a reason to get involved in the
process.
I'd be glad to discuss a plan to pursue this work within the IETF.
Thanks!
Kind regards,
--
Fernando Gont
e-mail: fernando at gont.com.ar || fgont at acm.org
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
Security Assessment of the Transmission Control Protocol (TCP)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hello, folks, I have just seen that there has been a thread about this document in this list, so here's a related "announcement": Last week the UK CPNI (United Kingdom's Centre for the Protection of National Infrastructure) released the document "Security Assessment of the Transmission Control Protocol (TCP)". The document analyzes the relevant specifications from a security point of view, and also analyzes the implications of some implementation strategies taken by popular TCP implementations. This document is available at: http://www.cpni.gov.uk/Docs/tn-03-09-security-assessment-TCP.pdf As part of the same project, we have produced an IETF I-D version of the UK CPNI document, in the hope that the IETF works on this stuff and hopefully publishes some version of the aforementioned document. The resulting IETF I-D is entitled "Security Assessment of the Transmission Control Protocol (TCP)" (draft-gont-tcp-security-00.txt) and is available at: http://tools.ietf.org/id/draft-gont-tcp-security-00.txt Any comments will be more than welcome. Thanks! Kind regards, - -- Fernando Gont e-mail: ferna...@gont.com.ar || fg...@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iQEcBAEBCAAGBQJJoJJ8AAoJEJbuqe/Qdv/xQ1gH/RYY8imAcxLInFgMoVAR0OLR UuTtYXxclpieRWNjEkJTpyiAA/q8czubkuP4kupp11CiL6nQxYZwV2mexG2/lQ91 Y1TWh9H1ofroWyU9ZMrYcz1PPOSeAY929Sn3U2yHKrm4QSVhH1NSBAVodTu2zKV6 jvhzny+IDtCrTIeRDZBZYKrFgkxA74vvzasXgj/A8JiPjbhN4zGABWxpsWV+d9Ti ceZBz8Ny+Mld/AQpag51OqFAVg4Xtzb9omDbxyc43B/YFzT+bTKMSLr3u68tH2xR xBFYJ50AZxuiayHxDZVHCAf4XrTFyCiD+iXpzlVWiSGcXBcLd6pziYBWdHVEbUo= =ftHE -END PGP SIGNATURE- ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Comments requested on recent appeal to the IESG
On Feb 19, 2009, at 6:04 PM, Dave CROCKER wrote: The IESG wrote: The IESG has received an appeal regarding the previously approved draft-kucherawy-sender-auth-header-20. The appeal text can be found here: http://www.ietf.org/IESG/APPEALS/appeal-otis-2009-02-16.txt This note offers comments on the appeal, draft-otis-auth-header- appeal-00, which has been lodged against standardization of draft- kucherawy-sender-auth-header-20. This appeal lacks merit on basic points. As a technical criticism, the appeal is confused and lacks substance. The conclusions appear to be based on fundamentally mis- reading of basic technical details of the specification. At best, the appeal makes the mistake of wanting to kill the messenger, rather than the message's author. That is, the appeal's authors appear to have concerns with certain types of report content, rather than with the mechanism of doing reporting. Yet auth-res is merely the mechanism, a common conduit for reporting a class of related information. Dave, Section 4.1 of this draft places the onus of checking associated reputations of "authenticated origin identifiers" on the MUA prior to revealing the content of the Authentication-Results header, but then fails to offer the necessary information for satisfying this requirement. Unfortunately, this draft's many confusing references to authorization mechanisms as authentication still does not offer, with any reasonable certainty, that an authorizing domain originated a message. The only weakly "authenticated origin identity" for either SPF or Sender-ID is the IP address of the SMTP client being authorized by an SPF record. When the SPF-SMTP-client authorization schemes were introduced, a client's failure to be authorized was to provide a basis for not accepting the message. Indeed, the appeal is dominated by criticisms of SPF and Sender-ID. The appeal's authors should express their concerns with those communities of interest, rather than with a mechanism that merely carries information that is generated by other mechanisms. The appeal attempts to clarify that *authorization* does not represent *authentication*. An authenticated SMTP client does not imply that it is authorized to issue a domain's message, neither does an authorized SMTP client imply that a domain offering authorization has therefore originated the message. It is the origin of the message and its role in protecting originating identifiers that is being trusted. The reputation of the "authenticated origin identity" ensuring this protection is what MUAs should depend upon. Look-alike attacks should not be accepted by border MTAs, but can still be thwarted proactively by the MUA with folder placement. As a statement of preference, the appeal lacks support. Contrary to the appeal authors' perspective, the bulk of the email reporting operations community find this mechanism helpful, in its current form. Whatever possible downsides the appeal's authors envision, it has not yet come to pass, over a long period of use. A desire to exclude the IP address of the SMTP client is likely aimed at avoiding repercussions that occur when issuing abusive messages. Rather than the reputation of a provider's ability to protect the use of a domain, the domain instead is expected to accrue the negative reputations. Unfairly assigning negative reputations to a domain not originating abusive messages can be disruptive and may invite litigations. Detailed comments follow: For such use, it is crucial to include within an "authenticated- results" header, a truly authenticated identity. Auth-res is specified as operating within a trust domain. It explicitly asserts the need for trusting the source of the report and the path from the report generator to the report consumer. As such, there is no obvious basis for claiming that further authentication of the report is needed. Section 4.1 correctly provides a basis for needing the "authenticated origin identifier". *Authorization* is not *authentication*. The draft acknowledges that it confuses authorization with authentication in section 1.5.2. No it does not. There is no language in 1.5.2 that describes or acknowledges any confusion. The only relevant text in that section is "this proposal groups them both into a single header field". Please review section 1.5.2 and then the many places where *authorization* is then referred to as *authentication*. The draft places all results into a header labeled "Authentication-Results" where the only identifier offered is that of the authorizing domain, and not that of the authenticated IP address of the SMTP client for Sender-ID or SPF. Consequently it appears that the real confusion is with the authors of the appeal, who confuse an explicit decision to allow two types of information to cohabit, with inability to dist
Re: Comments requested on recent appeal to the IESG
At 7:06 PM -0800 2/20/09, Dave CROCKER wrote: Stephen Kent wrote: At 9:00 PM -0800 2/19/09, Hallam-Baker, Phillip wrote: Just as a matter of observation, ... ... I have not read the doc in question,... Hey guys. As someone who is frequently faced with trying to parse out what are and are not the commonly held views among the security community, I'm actually interested in this type of exchange. But as you both note, this exchange isn't critical to resolution of the the appeal. For those of who want to see this appeal dispatched as quickly and as painlessly as possible, is there a chance that you can continue the exchange under a different guise, at a minimum under an entirely independent thread? d/ Dave, My belief is that IF the doc conflates authentication and authorization, then some intelligent editing probably can fix that problem quickly. Since, as you and other have noted, the WG is n board with this doc, the issue Phil raised, and to which I responded, ought not affect approval of the document. Steve ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
unsubscribe me from the ie mailing list
e mailin Add more friends to your messenger and enjoy! Go to http://messenger.yahoo.com/invite/___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Comments requested on recent appeal to the IESG
At 10:57 20-02-2009, Murray S. Kucherawy wrote: All of the issues Mr. Otis raises have been given substantially more than a normal amount of consideration, yet they have failed to attract any detectable consensus. Disagreement with both his concerns and his proposed remedies is ample and well-documented. As a participant to the discussions that lead to draft-kucherawy-sender-auth-header-20, I can confirm that the issues raised by Mr Otis were discussed on the mailing list - see http://mipassoc.org/pipermail/mail-vet-discuss/2008q4/000390.html http://mipassoc.org/pipermail/mail-vet-discuss/2008q4/000398.html http://mipassoc.org/pipermail/mail-vet-discuss/2008q4/000409.html http://mipassoc.org/pipermail/mail-vet-discuss/2008q4/000504.html http://mipassoc.org/pipermail/mail-vet-discuss/2008q4/000507.html http://mipassoc.org/pipermail/mail-vet-discuss/2009q1/000549.html http://mipassoc.org/pipermail/mail-vet-discuss/2009q1/000550.html http://mipassoc.org/pipermail/mail-vet-discuss/2009q1/000552.html http://mipassoc.org/pipermail/mail-vet-discuss/2009q1/000558.html During the IESG evaluation, a secdir review of draft-otis-auth-sender-sec-issues-00, which raises alleged security issues was requested. The appeal mentions that: 'In the case of Sender-ID or SPF, the deceptive nature of this header could have been remedied by including the "authenticated" IP address of the SMTP client, in addition to the authorizing domain.' That is at odds with the second paragraph of the appeal where the authors of the appeal point to the downside in the era of carrier grade NATs, virtual servers, aggregated services, and other techniques that overload the IP address. The appeal states that the its goal is to ensure adequate information is available when annotating email. The last paragraph mentions that an MTA adding this header field SHOULD NOT include any data which has not been authenticated by the method(s) being applied. It then proposes an exception for an Authorizing domain only when it accompanies the authenticated IP address of the SMTP client. Assigning a negative rating to an affected SMTP client IP addresses mitigates the security breach problem while completely blocking all messages from the domain and other domains hosted in a virtual server environment. Furthermore, basing MUA annotations on the rating of an IP address is questionable as messages are not always retrieved immediately after delivery. The appeal gets into a discussion about IPv6, SPF macros, and local-parts. draft-kucherawy-sender-auth-header-20 defines a header to capture email verification results. It is not about the internals of SPF. There is a recommended modification that the "pvalue" reported along with results for these mechanisms SHOULD NOT include the local-part. Quoting the draft under appeal, the value: For Sender ID: value of header field used by PRA after removing comments and parts not authenticated For SPF: envelope sender after removing parts not authenticated That cannot be interpreted as the local-part should be included. As for the confusion about authorization with authentication in section 1.5.2 of draft-kucherawy-sender-auth-header-20, there is a reference to BCP 72 and it quotes Section 4.4 which describes authorization and authentication. Authentication simply identifies a party, authorization defines whether they can perform a certain action. Authorization necessarily relies on authentication, but authentication alone does not imply authorization. draft-kucherawy-sender-auth-header-20 describes SPF and Sender ID as authorization mechanisms in that they express a result that shows whether or not the ADMD that apparently sent the message has explicitly authorized the connecting SMTP client to relay messages on its behalf but do not actually validate any property of the message itself. The author of the draft mentions that rather than create a separate header field for each class of solution, this proposal groups them both into a single header field. Regards, -sm ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
