RE: Last Call: draft-ietf-nea-pt-eap-06.txt (PT-EAP: Posture Transport (PT) Protocol For EAP Tunnel Methods) to Proposed Standard
Changing our reference to RFC 5209 to be normative may cause more problems than it solves. As RFC 3967 (BCP 97) says, IETF procedures generally require that a standards track RFC may not have a normative reference to another standards track document at a lower maturity level or to a non standards track specification (other than specifications from other standards bodies). For example, a standards track document may not have a normative reference to an informational RFC. Generally, documents that contain use cases or architectures are Informational. References to such documents in a standards track document are informative because referring to the use cases is not required in order to implement the standard. RFC 5209 lists use cases for NEA, describes a reference model for NEA, and includes requirements that the NEA protocols must meet. None of the requirements in RFC 5209 are requirements on implementations of the NEA protocols. Therefore, the PT-EAP spec should not include a normative reference to RFC 5209. And that's good, because RFC 5209 is an Informational RFC. If I've missed something (e.g. a reason why the reference should be normative), please explain it more clearly. Thanks, Steve -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of SM Sent: Monday, January 14, 2013 4:34 PM To: Nancy Cam-Winget (ncamwing) Cc: ietf-priv...@ietf.org; n...@ietf.org; ietf@ietf.org Subject: Re: Last Call: draft-ietf-nea-pt-eap-06.txt (PT-EAP: Posture Transport (PT) Protocol For EAP Tunnel Methods) to Proposed Standard Hi Nancy, At 12:29 14-01-2013, Nancy Cam-Winget (ncamwing) wrote: [NCW] I can change it to a lower case must, ok? That's ok. [NCW] We can move the reference to be normative. Ok. [NCW] I don't think there are specifically for PT-EAP. The sections you reference Were to (in section 6) addressing the general EAP identity as PT-EAP is really not An authentication method. If I understood the above correctly PT-EAP does not transport any information which could be used to identify an individual. That's different from PT-EAP not being an authenticated method. Therefore, there isn't much to say in terms of privacy considerations. I suggest not including the following then: As a transport protocol, PT-EAP does not directly utilize or require direct knowledge of any personally identifiable information (PII). The draft can leverage the second paragraph of Section 6 as privacy considerations instead of making a statement about PII. I'll copy this message to ietf-privacy@ to get a better opinion. In Section 6: Therefore, it is important for deployers to leverage these protections in order to prevent disclosure of PII potentially contained within PA-TNC or PB-TNC within the PT-EAP payload. I suggest information about an individual instead of PII [1]. Regards, -sm 1. I used the wording from draft-iab-privacy-considerations-06
RE: travel guide for the next IETF...
Dean Willis wrote: Having a car won't do any good. There is, as far as I can tell, no place to park it but the hotel valet. According to this web page, complimentary self-parking is available at the Caribe Royale. http://www.cariberoyale.com/accommodations/services/ Thanks, Steve
RE: Recall petition for Mr. Marshall Eubanks
I also, with regret, would like to add my name to the recall petition. I am NomCom eligible. Thanks, Steve
secdir review of draft-ietf-6lowpan-btle-08
I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document describes how IPv6 is transported over Bluetooth Low Energy (BT-LE). As a proviso, I am not an expert in IPv6, 6LoWPAN, or Bluetooth. Still, this document seemed to be a clear specification of the intended subject matter. The Security Considerations section says that the security concerns are similar to those for IPv6 over 802.15.4. That makes sense, I suppose. I was happy to see that this document says IPv6 over BT-LE SHOULD be protected by using BT-LE Link Layer security, whereas RFC 4944 (IPv6 over 802.15.4) does not include any normative language on using link layer security. Also, this document says that Key management in BT-LE is provided by the Security Manager Protocol (SMP), whereas RFC 4944 says that no key management is provided by 802.15.4. So this specification is apparently more secure that RFC 4944. That's good. So based on my review (admitting little knowledge of BT-LE), this document seems to be an improvement over the current state of the art for 6LoWPAN from a security perspective. And the overall level of security seems reasonable. I have no objection to the publication of this document. I did notice two typos: gateway^1s = gateway's respectively = respectively Thanks, Steve
Updated secdir review of draft-ietf-emu-chbind-16.txt
Sam, Thanks for addressing my comments in draft-ietf-emu-chbind-16.txt. I'm happy with this version. All my substantive concerns are addressed. I do see two non-substantive issues. These can be addressed in some future version or not at all. 1) The word subvert is misspelled as subvirt in the new text. 2) Editing Charles Clancy's address in the Authors' Addresses section has apparently caused the list of authors in the top right corner of the first page to revert to this suboptimal form: EMU Working GroupS. Hartman, Ed. Internet-Draft Painless Security Intended status: Standards Track T. Clancy Expires: November 25, 2012 Department of Electrical Engineering and Computer Science K. Hoeper Motorola Solutions, Inc. As you can see, Dr. Clancy's affiliation has now changed back to Department of Electrical Engineering and Computer Science. I guess that whatever tool you're using to create the draft must insist on placing the second line of each author's address on the first page. If that's the case, you might want to change Dr. Clancy's address to T. Charles Clancy Virginia Tech Department of Electrical Engineering and Computer Science Arlington, VA 22203 USA Or perhaps you'll just have to surrender to the flawed tool and leave the credit for Dr. Clancy on the first page as nonsensical. Thanks for your patience in addressing the issues that I raised. I think the document is much better for this attention. Take care, Steve -Original Message- From: Stephen Hanna Sent: Tuesday, May 22, 2012 4:00 PM To: 'Sam Hartman' Cc: e...@ietf.org; sec...@ietf.org; ietf@ietf.org Subject: RE: Updated secdir review of draft-ietf-emu-chbind-15.txt Sam, I see now that you are concerned not with circumstances where the NAS terminates the tunnel by design but rather with times when the NAS is maliciously terminating the tunnel. I'm glad that we both agree that having the NAS terminate the tunnel is highly undesirable. That did not come through in the draft. I'm much relieved to learn that nobody is suggesting this as a desirable outcome. I agree that it's an attack scenario that must be considered and carefully addressed. Maybe we can resolve this issue by clarifying the text to say more clearly that we're dealing with an attack scenario here. For example, we could add a sentence before the words Tunnel methods sometimes use saying something like However, this is not secure if the NAS can terminate the tunnel (a highly undesirable situation). Then you can mention several countermeasures against such an attack: mutual cryptographic bindings (still just a -00 individual draft), carefully checking the EAP server's identity, etc. We might also take this opportunity to split this long paragraph into two: one that includes the first three sentences (describing how EAP tunnel methods can support channel binding) and another describing the attack scenario and countermeasures. Thanks, Steve -Original Message- From: Sam Hartman [mailto:hartmans-i...@mit.edu] Sent: Monday, May 21, 2012 5:51 PM To: Stephen Hanna Cc: Sam Hartman; e...@ietf.org; sec...@ietf.org; ietf@ietf.org Subject: Re: Updated secdir review of draft-ietf-emu-chbind-15.txt Importance: High Stephen == Stephen Hanna sha...@juniper.net writes: Stephen The changes in draft-ietf-emu-chbind-15.txt satisfactorily Stephen address almost all of the comments in my April 13, 2012 Stephen secdir review. I do have one remaining substantive comment Stephen on this latest draft and two non-substantive ones. Stephen Substantive Comment --- Stephen The last paragraph of section 9.1 points out a security Stephen problem with implementing channel bindings using EAP tunnel Stephen methods. If the EAP tunnel method terminates on the Stephen authenticator, the channel bindings can easily be defeated Stephen by the authenticator. While that's true, nobody terminates Stephen the EAP tunnel method on the authenticator today. In the Stephen EAP model, the authenticator is not trusted so terminating Stephen the EAP tunnel method on the authenticator is a bad idea Stephen for many reasons. For example, the authenticator would then Stephen have the ability to bypass protected result indications and Stephen to bypass all the cryptographic protections provided by the Stephen tunnel. Sometimes there is value in having the inner and Stephen outer methods terminate on different servers but both Stephen servers must be trusted. The authenticator is not. So
RE: Updated secdir review of draft-ietf-emu-chbind-15.txt
Sam, I see now that you are concerned not with circumstances where the NAS terminates the tunnel by design but rather with times when the NAS is maliciously terminating the tunnel. I'm glad that we both agree that having the NAS terminate the tunnel is highly undesirable. That did not come through in the draft. I'm much relieved to learn that nobody is suggesting this as a desirable outcome. I agree that it's an attack scenario that must be considered and carefully addressed. Maybe we can resolve this issue by clarifying the text to say more clearly that we're dealing with an attack scenario here. For example, we could add a sentence before the words Tunnel methods sometimes use saying something like However, this is not secure if the NAS can terminate the tunnel (a highly undesirable situation). Then you can mention several countermeasures against such an attack: mutual cryptographic bindings (still just a -00 individual draft), carefully checking the EAP server's identity, etc. We might also take this opportunity to split this long paragraph into two: one that includes the first three sentences (describing how EAP tunnel methods can support channel binding) and another describing the attack scenario and countermeasures. Thanks, Steve -Original Message- From: Sam Hartman [mailto:hartmans-i...@mit.edu] Sent: Monday, May 21, 2012 5:51 PM To: Stephen Hanna Cc: Sam Hartman; e...@ietf.org; sec...@ietf.org; ietf@ietf.org Subject: Re: Updated secdir review of draft-ietf-emu-chbind-15.txt Importance: High Stephen == Stephen Hanna sha...@juniper.net writes: Stephen The changes in draft-ietf-emu-chbind-15.txt satisfactorily Stephen address almost all of the comments in my April 13, 2012 Stephen secdir review. I do have one remaining substantive comment Stephen on this latest draft and two non-substantive ones. Stephen Substantive Comment --- Stephen The last paragraph of section 9.1 points out a security Stephen problem with implementing channel bindings using EAP tunnel Stephen methods. If the EAP tunnel method terminates on the Stephen authenticator, the channel bindings can easily be defeated Stephen by the authenticator. While that's true, nobody terminates Stephen the EAP tunnel method on the authenticator today. In the Stephen EAP model, the authenticator is not trusted so terminating Stephen the EAP tunnel method on the authenticator is a bad idea Stephen for many reasons. For example, the authenticator would then Stephen have the ability to bypass protected result indications and Stephen to bypass all the cryptographic protections provided by the Stephen tunnel. Sometimes there is value in having the inner and Stephen outer methods terminate on different servers but both Stephen servers must be trusted. The authenticator is not. So Stephen there is no big security hole here, unless you have already Stephen opened an enormous security hole. It's ironic that this Stephen document which attempts to close vulnerabilities caused by Stephen malicious authenticators ends up subtly suggesting that Stephen people open a much larger vulnerability! Stephen I would recommend deleting the end of this paragraph, Stephen starting with the sentence that starts Even when Stephen cryptographic binding. I disagree very strongly with this proposed change. It's possible that the text is not clear and I'd be happy to work for a round or two to see if we can clarify the text, but ending the paragraph as you propose would defeate the point of text we added after a WG consensus call. I agree with you that authenticators are not trusted. The issue is that you cannot trust attackers to act within a specification. If an attacker can gain benefit from doing something, they may do so. So, if an attacker can create a tunnel terminating at an authenticator and gain advantage from doing so, then they will do so. Remember that we're talking about crypto binding. If crypto binding is relevant for confirming there are no extra servers, then we're in a threat model space where we're trusting the inner method to authenticate the server, not the outer method. You can't say you should only establish trusted tunnels, because we're hoping that crypto binding will give us that trust. So, the issue here is that once you add channel bindings and the associated changes to the threat model to EAP, an authenticator can gain advantage through convincing a client to trust a tunnel that terminates at an authenticator. That is, an authenticator can mount an attack. Yes, the authenticator needs to convince the peer to trust the extra tunnel. However, as I discuss in draft-hartman-emu-mutual-crypto-binding and in my presentation at last IETF, that's often fairly easy. So, how can we make the text more clear?
Updated secdir review of draft-ietf-emu-chbind-15.txt
The changes in draft-ietf-emu-chbind-15.txt satisfactorily address almost all of the comments in my April 13, 2012 secdir review. I do have one remaining substantive comment on this latest draft and two non-substantive ones. Substantive Comment --- The last paragraph of section 9.1 points out a security problem with implementing channel bindings using EAP tunnel methods. If the EAP tunnel method terminates on the authenticator, the channel bindings can easily be defeated by the authenticator. While that's true, nobody terminates the EAP tunnel method on the authenticator today. In the EAP model, the authenticator is not trusted so terminating the EAP tunnel method on the authenticator is a bad idea for many reasons. For example, the authenticator would then have the ability to bypass protected result indications and to bypass all the cryptographic protections provided by the tunnel. Sometimes there is value in having the inner and outer methods terminate on different servers but both servers must be trusted. The authenticator is not. So there is no big security hole here, unless you have already opened an enormous security hole. It's ironic that this document which attempts to close vulnerabilities caused by malicious authenticators ends up subtly suggesting that people open a much larger vulnerability! I would recommend deleting the end of this paragraph, starting with the sentence that starts Even when cryptographic binding. If you choose to keep this strange text, I suggest that you at least note that terminating an EAP tunnel method on the authenticator is unusual. For example, you could add a parenthetical comment like (rare) after the clause if the outer method tunnel terminates on the authenticator. Non-Substantive Comments In the first paragraph of section 3, an extraneous numeral 3 was somehow added to the end of the second sentence. T. Charles Clancy's address in the Authors' Addresses section now reads: T. Charles Clancy Virginia Tech Virginia Tech Arlington, VA 22203 USA The duplication of Virginia Tech should be removed from this address. I appreciate the hard work of the document editors to address my many earlier comments. I hope that these new comments will also be useful. Thanks, Steve
RE: [secdir] secdir review of draft-ietf-emu-chbind-14
Thanks, Joe. Looks like we've reached agreement on most things. There are a few items left where Sam's input is needed. I'll wait to see what he has to say. Thanks, Steve -Original Message- From: Joe Salowey [mailto:jsalo...@cisco.com] Sent: Wednesday, April 25, 2012 1:34 AM To: Stephen Hanna Cc: draft-ietf-emu-chb...@tools.ietf.org; sec...@ietf.org; IETF- Discussion list; Sam Hartman Subject: Re: [secdir] secdir review of draft-ietf-emu-chbind-14 Importance: High On Apr 24, 2012, at 2:05 PM, Stephen Hanna wrote: Joe, I'm glad that my comments were useful to you and to the editors of this draft. I will respond to your comments below inline. I'm going to clip out as much as I can, including anything that has already been agreed on. Thanks, Steve -- Joe Salowey wrote: On Apr 13, 2012, at 11:26 AM, Stephen Hanna wrote: In the Introduction, the second paragraph says that the problem results when the same credentials are used to access multiple services that differ in some interesting property. Do you mean client or server credentials? I think you mean EAP server credentials. Please be more explicit to make this clearer, since many people will assume that you mean client (EAP peer) credentials. If I'm correct and you do mean EAP server credentials, I suggest that you say so in the first sentence of this paragraph and also in the last sentence. [Joe] The case here is both client and server credentials. If different credentials are required for each type of service then the authenticator will not be able to lie about the type of service it is representing to the client because the client credentials are bound to the service. SH I don't see what the problem is with using the same client credentials with two different services if the server credentials are different. The client will be able to detect a lying NAS easily since the server credentials won't match what it expects for that service. Could you please explain this more? [Joe] In many cases the server credentials will be the same. They will be the credentials of the AAA server. In the first paragraph of the Problem Statement, the second sentence says However, when operating in pass-through mode, the EAP server can be far removed from the authenticator. While this is true, I think the more relevant statement here is that the EAP server can be far removed from the EAP peer. This paragraph is all about problems that can arise when parties between the EAP peer and the EAP server (including the authenticator) are malicious or compromised. So the important thing to point out at the start of the paragraph is the large number of parties that may come between the EAP server and the EAP peer. [Joe] I think I see your point, but I'm not sure. Traditionally, we have often thought of the path between EAP peer and EAP authenticator as being vulnerable to having multiple parties able to insert themselves into the conversation. However it may be the case that the authenticator the peer is talking to isn't the one it thinks it is and the real authenticator may be somewhere in the path as well. The conversation between the EAP peer and EAP server will not be compromised, however the result of the conversation may not have its intended effect. My point is that having a long distance between the EAP server and the authenticator has little to do with the lying NAS problem. The problem is that there are potentially untrustworthy parties (the NAS and any proxies) between the EAP peer and the EAP server and the EAP peer is trusting what it's told by them. If the EAP server and the authenticator were two inches apart with no intermediaries, that wouldn't help. The problem is the potentially untrustworthy folks between the EAP server and the EAP peer. You're trying to verify some of what they're telling the EAP peer. So I'm not sure that sentence helps but if it does, the problem is between the EAP peer and the EAP server. [Joe] I don't have an issue with stating that the problem is between the peer and the server, but I'd like to hear the author's view on this. [Joe] THis is historical and reflects the discussion we had in the working as the document was being developed. I see several downsides to including that text in this document. First, you're making it harder for the reader to understand what they actually need to do to implement this protocol. You've probably decreased by half the number of people who will actually read all of this document. Second, some people will use that digression to support arguments like (My incompatible implementation is compliant with RFC because I encoded the network information into a blob and used that to generate EAP session keys). IETF is an engineering organization. We should make our specs as clear
RE: secdir review of draft-nottingham-http-new-status-03
Mark, I don't want to rehash the discussion that we've already had. Clearly, you prefer brevity while I would prefer education in this instance. I can live with your text for status codes 428, 429, and 431. For 511, I don't think it's adequate to just say that big security issues already exist. You should at least give some suggestions for how to deal with them. For example, you could point out that most user agents include some indication of whether the server has been authenticated. For captive portals, this indication will generally not be displayed so the user receives some warning that the response did not come from the requested URL. Thanks, Steve -Original Message- From: Mark Nottingham [mailto:m...@mnot.net] Sent: Sunday, January 29, 2012 6:50 PM To: Stephen Hanna Cc: Julian Reschke; draft-nottingham-http-new-sta...@tools.ietf.org; sec...@ietf.org; ietf@ietf.org Subject: Re: secdir review of draft-nottingham-http-new-status-03 I haven't heard any further response. After a reminder from a Security AD, I took another look at the spec. E.g., the current Security Considerations for 428: The 428 status code is optional; clients cannot rely upon its use to prevent lost update conflicts. Like many of the status codes, that's already a risk inherent in using HTTP today; we're effectively just noting that we can't force implementations to use the new status code retroactively, so they can't use the publication of this document as a magical flag day. As such, not much more can be said; the only way that people can further mitigate the risks of lost updates is to have a private, out- of-band agreement to use 429, and I *don't* think that's something we should be encouraging. For 429, I've changed to: When a server is under attack or just receiving a very large number of requests from a single party, responding to each with a 429 status code will consume resources. Therefore, servers are not required to use the 429 status code; when limiting resource usage, it may be more appropriate to just drop connections, or take other steps. 431 says: Servers are not required to use the 431 status code; when under attack, it may be more appropriate to just drop connections, or take other steps. What else should be said here? This specification is not a treatise on dealing with denial-of-service attacks; all that it notes is that servers aren't required to use the status code. Finally, 511 says: In common use, a response carrying the 511 status code will not come from the origin server indicated in the request's URL. This presents many security issues; e.g., an attacking intermediary may be inserting cookies into the original domain's name space, may be observing cookies or HTTP authentication credentials sent from the user agent, and so on. However, these risks are not unique to the 511 status code; in other words, a captive portal that is not using this status code introduces the same issues. Are there other specific threats you're aware of here? Regards, On 25/01/2012, at 10:36 AM, Mark Nottingham wrote: Sorry for the delay in responding; just back from holiday. On 14/01/2012, at 8:26 AM, Stephen Hanna wrote: Julian, I'm sure that in your view one sentence is adequate to explain all the security implications of each status code. However, you may want to consider that some readers may not have quite the same deep grasp of the matter that you do. Therefore, I think it would be wise to provide more explanation. Here's an example for section 7.2 on status code 429 (Too Many Requests): Section 7.2 429 Too Many Requests While status code 429 can be helpful in figuring out why a server is not responding to requests, it can also be harmful. When a server is under attack or simply receiving a very large number of requests from a single party, responding to each of these requests with a 429 status code will consume resources that could be better used in other ways. Therefore, a server in such circumstances may choose to send a 429 status code only the first time a client exceeds its limit and ignore subsequent requests from this client until its limit is no longer exceeded. Other approaches may also be employed. As you can see, I described security problems that could occur with this status code and explained how those problems can be avoided or mitigated. While it's true that these problems could occur when a more generic status code is used to handle the case of too many requests, that does not mean that they are not relevant to this document. On the contrary, the fact that this document is providing more detailed status codes gives us the opportunity and one can argue the obligation to provide more detailed security analysis relevant to these more detailed status codes. I'm really not sure I agree; the original text is: Servers
RE: secdir review of draft-nottingham-http-new-status-03
Yes -Steve -Original Message- From: Julian Reschke [mailto:julian.resc...@gmx.de] Sent: Monday, January 30, 2012 10:10 AM To: Stephen Hanna Cc: Mark Nottingham; draft-nottingham-http-new-sta...@tools.ietf.org; sec...@ietf.org; ietf@ietf.org Subject: Re: secdir review of draft-nottingham-http-new-status-03 On 2012-01-30 16:05, Stephen Hanna wrote: Mark, I don't want to rehash the discussion that we've already had. Clearly, you prefer brevity while I would prefer education in this instance. I can live with your text for status codes 428, 429, and 431. For 511, I don't think it's adequate to just say that big security issues already exist. You should at least give some suggestions for how to deal with them. For example, you could point out that most user agents include some indication of whether the server has been authenticated. For captive portals, this indication will generally not be displayed so the user receives some warning that the response did not come from the requested URL. Are you referring to HTTPS? Best regards, Julian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
secdir review of draft-nottingham-http-new-status-03
I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document specifies new HTTP status codes for a variety of common situations. Although I am not an HTTP expert, it seems to me that this document is clear, well-written, and reasonable. From a security perspective, this document seems to have little impact either positive or negative. However, the Security Considerations section does not meet our usual standards. While the authors include a subsection on each new status code, they do not explain clearly what the security implications are for each status code and how any possible negative impacts could be reduced. Riccardo Bernardini already commented on this issue during IETF LC. However, I do not agree with Mr. Bernardini that sections 7.1 and 7.2 are not security related. Rather, the security implications are just not clearly stated. For example, section 7.2 points out that servers may not want to always use the 429 status code when receiving too many requests from one client. This has security implications in that a server under attack with excessive requests from one client may compound the problem by queuing 429 status codes for every request from that client. However, this is not stated explicitly in section 7.2. Fleshing out the subsections of section 7 (Security Considerations) should help solve the problem by providing a clear description of security problems related to these result codes and recommended mitigations. Section 7.4 does a decent job of describing the problems but fails to describe mitigations. I think that having the client use HTTPS instead of HTTP for important requests and limiting the effects of HTTP (not HTTPS) responses is an obvious mitigation. I do have a question about the issues raised in Appendix B. These are all legitimate issues. However, it seems to me that having status code 511 should help with these. A browser or non-browser application could recognize status code 511 as an indication that a captive portal is in use and avoid capturing favicons, looking for P3P files, and doing other things that should wait until after the captive portal is blocking access. When the original website stops returning 511, such activities could resume. I may be wrong in suggesting these ideas but if not it would be good to note them here. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: secdir review of draft-nottingham-http-new-status-03
Julian, I'm sure that in your view one sentence is adequate to explain all the security implications of each status code. However, you may want to consider that some readers may not have quite the same deep grasp of the matter that you do. Therefore, I think it would be wise to provide more explanation. Here's an example for section 7.2 on status code 429 (Too Many Requests): Section 7.2 429 Too Many Requests While status code 429 can be helpful in figuring out why a server is not responding to requests, it can also be harmful. When a server is under attack or simply receiving a very large number of requests from a single party, responding to each of these requests with a 429 status code will consume resources that could be better used in other ways. Therefore, a server in such circumstances may choose to send a 429 status code only the first time a client exceeds its limit and ignore subsequent requests from this client until its limit is no longer exceeded. Other approaches may also be employed. As you can see, I described security problems that could occur with this status code and explained how those problems can be avoided or mitigated. While it's true that these problems could occur when a more generic status code is used to handle the case of too many requests, that does not mean that they are not relevant to this document. On the contrary, the fact that this document is providing more detailed status codes gives us the opportunity and one can argue the obligation to provide more detailed security analysis relevant to these more detailed status codes. And I'm glad that you saw the value in my comment about Appendix B! Thanks, Steve -Original Message- From: Julian Reschke [mailto:julian.resc...@gmx.de] Sent: Friday, January 13, 2012 3:27 PM To: Stephen Hanna Cc: draft-nottingham-http-new-sta...@tools.ietf.org; sec...@ietf.org; ietf@ietf.org Subject: Re: secdir review of draft-nottingham-http-new-status-03 On 2012-01-13 20:59, Stephen Hanna wrote: I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document specifies new HTTP status codes for a variety of common situations. Although I am not an HTTP expert, it seems to me that this document is clear, well-written, and reasonable. +1 From a security perspective, this document seems to have little impact either positive or negative. However, the Security Considerations section does not meet our usual standards. While the authors include a subsection on each new status code, they do not explain clearly what the security implications are for each status code and how any possible negative impacts could be reduced. In general, the proposed new codes just allow to describe a problem more clearly; previously, a more generic status code would have to be used. As such, they do not change security at all. Riccardo Bernardini already commented on this issue during IETF LC. However, I do not agree with Mr. Bernardini that sections 7.1 and 7.2 are not security related. Rather, the security implications are just not clearly stated. For example, section 7.2 points out that servers may not want to always use the 429 status code when receiving too many requests from one client. This has security implications in that a server under attack with excessive requests from one client may compound the problem by queuing 429 status codes for every request from that client. However, this is not stated explicitly in section 7.2. Fleshing out the subsections Servers are not required to use the 429 status code; when limiting resource usage, it may be more appropriate to just drop connections, or take other steps. of section 7 (Security Considerations) should help solve the problem by providing a clear description of security problems related to these result codes and recommended mitigations. Section 7.4 does a decent job of describing the problems but fails to describe mitigations. I think that having the client use HTTPS instead of HTTP for important requests and limiting the effects of HTTP (not HTTPS) responses is an obvious mitigation. It's not the job of this spec to completely describe security considerations with respect to captive portals. All the spec does is defining a new status code that, when used, makes captive portals a bit better to work with. I do have a question about the issues raised in Appendix B. These are all legitimate issues. However, it seems to me that having status code 511 should help with these. A Indeed; that's why 511 is there in the first place. The introduction to Appendix B should state
Secdir review of draft-ietf-dime-priority-avps-05
I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This standards track document defines Diameter AVPs that can be used to convey a variety of priority parameters. In July 2011, I conducted a secdir review of a previous revision of this document (-04) and found that the Security Considerations section was inadequate because it did not include any analysis of the specific security issues related to priority systems. I'm pleased to say that the authors have attempted to address this issue in their new draft. They added a reference to the Security Considerations section of RFC 5866, which is thorough and sound. In addition, they explicitly identify one threat: unauthorized changes to QoS parameters in transit. However, the countermeasure proposed is confusing. The document now says integrity protected values SHOULD be ignored. I would expect the reverse. Values that are not integrity protected SHOULD be ignored. Am I wrong? I'm concerned that the other threats described in RFC 5866 are not addressed in this document. Lack of authentication and confidentiality protection for QoS parameters can have serious negative impacts, as described in RFC 5866. In the IETF spirit of send text, I suggest the following paragraph be added to the Security Considerations section of this draft: As described in [RFC5866], failure to provide adequate authentication and confidentiality protection for QoS parameters may result in serious failures that undermine the very purpose of QoS. Countermeasures such as Diameter communication security should be employed as appropriate. I will supply a further optional suggestion to clarify the text recently added regarding integrity. I recommend that the first paragraph of the Security Considerations section be stripped to just its first sentence and that the following paragraph be used in place of the new text that was added at the end of that paragraph: The values in the AVPs defined in this draft are not supposed to be changed by any of the Diameter servers or any other intermediaries. In fact, changes to these AVPs in transit could result in serious problems such as inability to complete high-priority emergency phone calls. Therefore, source integrity protection SHOULD be employed for those AVPs (e.g., the use of S/MIME with the SIP RPH, or an INTEGRITY object within a POLICY_DATA object). The text that I wrote may well be incorrect or misguided. I'm just trying to provide helpful suggestions from a security perspective. If the authors would like to have a further chat about this topic, I'd be glad to do so. And if they want to keep the text that they added on integrity protection, that's OK. I just found it a bit lacking in describing the threat and its consequences and in providing an effective countermeasure. Thanks, Steve ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: secdir review of draft-ietf-dime-priority-avps-04
Thanks for your response, Ken. Removing the last sentence that you quoted would make things worse. Readers of this draft should definitely familiarize themselves with the security considerations related to priority. We should make that easier, not harder. The fact that those considerations also apply to other RFCs does not remove the fact that they apply to this one also. You cannot publish a document whose security considerations section says (as this one effectively does today), There are lots of security considerations related to this document. To understand them, please dig through all the referenced documents and figure it out yourself. Doing that digging and analysis is the job of the document editors. In order to ease the burden on you, I think a reasonable compromise would be for YOU to review the documents referenced and decide which have the most relevant security considerations. Then you could list those explicitly in the last paragraph of the Security Considerations. Thanks, steve -Original Message- From: carlb...@g11.org.uk [mailto:carlb...@g11.org.uk] Sent: Tuesday, July 26, 2011 6:42 AM To: Stephen Hanna Cc: ietf@ietf.org; sec...@ietf.org; draft-ietf-dime-priority- avps@tools.ietf.org; lionel.mor...@orange-ftgroup.com Subject: re: secdir review of draft-ietf-dime-priority-avps-04 Hi Steve, Thanks for the review. snip This standards track document defines Diameter AVPs that can be used to convey a variety of priority parameters. While the Security Considerations section of this document properly requires that implementers review the Security Considerations section in the Diameter protocol specification and consider the issues described there, it does not include any analysis of the specific security issues related to priority systems. The authors should review other Security Considerations sections relating to priority systems (e.g. the one in RFC 4412) and add text that describes the special security issues that arise with priority systems and the countermeasures that may be employed. You raise an interesting issue and we actually had a discussion about this on the DIME list http://www.ietf.org/mail-archive/web/dime/current/msg04773.html And just for the sake of completeness, here is the security considerations text of the dime-priority-avps draft in question: This document describes the extension of Diameter for conveying Quality of Service information. The security considerations of the Diameter protocol itself have been discussed in [I-D.ietf-dime-rfc3588bis]. Use of the AVPs defined in this document MUST take into consideration the security issues and requirements of the Diameter base protocol. The authors also recommend that readers should familiarize themselves with the security considerations of the various protocols listed in the Normative References listed below. In a nutshell, the authors and the chair disagreed with the need for extending the security considerations to include an analysis with other protocols (eg, rfc-4412) because these protocols operate outside of the DIAMETER protocol. The dime-priority-avps draft is an extension of I-D.ietf-dime-rfc3588bis, and thus is subject to the same security considerations to the bis draft. And its also important to keep in mind that the dime-priority-avps draft does not inject prioritization into the exchange of DIAMETER messages. It simply defines AVPs that correlate to some priority fields of other protocols. If it was the last sentence (above) in the dime-priority-avps security considerations that has triggered your comment about further analysis, then I'd prefer just removing that text. cheers, -ken ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: secdir review of draft-ietf-dime-priority-avps-04
Every RFC author has an obligation to explain in the Security Considerations section what security issues are likely to arise when this specification is used and how those issues may be addressed. You can refer to other RFCs if you like but you cannot ignore the issues or just give a hand wave. Let me give a specific example. If a user is able to ensure that their phone calls always get the highest SIP-Resource-Priority, their calls will always go through, even during a disaster. This will benefit the user so they have an incentive to do it. However, it may damage the collective if calls from emergency responders are overridden. For this reason, protection against active MITM attacks SHOULD be employed when using Priority AVPs. If you can find an extant RFC that covers the relevant Security Considerations for your document, you can point to it and say that readers should review it because the security considerations for this draft are contained there. But you must perform a serious security analysis for your document if you want it to be accepted as an RFC. If the answer is that there are no security considerations, that's fine. You can say that. But in this case, that's clearly not the case. You raised the concern that documents may need to highlight security issues with underlying protocols upon which they depend. That is true. If you're depending on a protocol that has a serious security problem that's relevant to your document, you should explain that problem or point to a document that does so. If the problem is not relevant to your document, no problem. One need not consider every possible security issue, just the ones that are most relevant to your document. In your case, there are real security issues particular to conveying priority AVPs over Diameter. You should explain what those considerations are or point to documents that do so. As for MIBs, take a look at some recent ones and you will see that they do contain good Security Considerations sections. For example, see RFC 5834 and RFC 6240. If you'd like to learn more about how to write a good Security Considerations section, read RFC 3552. Or ask a security expert to help you. If you can't be bothered to think about security, you might as well withdraw your draft from consideration. Thanks, Steve -Original Message- From: carlb...@g11.org.uk [mailto:carlb...@g11.org.uk] Sent: Tuesday, July 26, 2011 7:24 AM To: Stephen Hanna Cc: ietf@ietf.org; sec...@ietf.org; draft-ietf-dime-priority- avps@tools.ietf.org; lionel.mor...@orange-ftgroup.com Subject: RE: secdir review of draft-ietf-dime-priority-avps-04 Steve, Quoting Stephen Hanna sha...@juniper.net: Thanks for your response, Ken. Removing the last sentence that you quoted would make things worse. Readers of this draft should definitely familiarize themselves with the security considerations related to priority. We should make that easier, not harder. The fact that those considerations also apply to other RFCs does not remove the fact that they apply to this one also. but those considerations do not directly apply to DIAMETER. You cannot publish a document whose security considerations section says (as this one effectively does today), There are lots of security considerations related to this document. To understand them, please dig through all the referenced documents and figure it out yourself. Doing that digging and analysis is the job of the document editors. agreed, speaking in the general sense. But again, the security considerations of these other protocols do not apply to the operation of Diameter. In order to ease the burden on you, I think a reasonable compromise would be for YOU to review the documents referenced and decide which have the most relevant security considerations. Then you could list those explicitly in the last paragraph of the Security Considerations. I'm concerned about the implications of your recommendation. If we extend this position to other work in the IETF, then efforts like defining MIBs would mean that each MIB draft would need to perform a security considerations analysis of each protocol that an objects refers to in the context of SNMP. And one can extend the argument that each protocol operating on top of TCP (and/or UDP) and IP would need to perform an analysis on how TCP/UDP and IP may affect the upper layer protocol. We don't do that today. cheers, -ken ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Secdir review of draft-ietf-dime-priority-avps-04
I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This standards track document defines Diameter AVPs that can be used to convey a variety of priority parameters. While the Security Considerations section of this document properly requires that implementers review the Security Considerations section in the Diameter protocol specification and consider the issues described there, it does not include any analysis of the specific security issues related to priority systems. The authors should review other Security Considerations sections relating to priority systems (e.g. the one in RFC 4412) and add text that describes the special security issues that arise with priority systems and the countermeasures that may be employed. Thanks, Steve ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
secdir review of draft-ietf-dnsext-rfc2672bis-dname-22.txt
I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document intends to replace RFC 2672, the definition of DNAME redirection in the DNS. DNAME is a DNS resource record type that (in layman's terms) indicates that all domain names ending in a specified suffix should be redirected to domain names where the suffix is replaced by a specified value. For example, all names that end with example.com should be remapped to example.net. The document is quite thorough, apparently because the DNAME RR has been used for many years and a great deal of real-world experience has been gained. That's definitely a good thing! From a security perspective, this document includes a more thorough analysis of security considerations than the original RFC 2672. It also includes a more thorough discussion of DNSSEC interactions than the earlier document. I do not see any security issues that are not well covered in this document. While I don't think this document will close any major security issues, it includes some helpful guidance. So I recommend that this document advance to RFC status. Thanks, Steve ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
secdir review of draft-ietf-ipfix-mediators-framework-09.txt
I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document adds a new concept to the IPFIX architecture (RFC 5470): IPFIX Mediation. This concept allows conversion, correlation, selection, and other transformations on IPFIX records. The document is clear and the Security Considerations section seems to adequately cover the issues raised. I don't see any problems from a security perspective. Thanks, Steve ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
secdir review of draft-ietf-csi-dhcpv6-cga-ps-04.txt
I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document discusses several ways that DHCPv6 can be used with Cryptographically Generated Addresses (CGA), pointing out benefits and concerns. While the document does discuss security issues in several places, it often lapses into vague terminology like one should carefully consider the impact on security. Given that the primary benefit of using CGAs is to improve security by providing address validation without complex key distribution, carefully analyzing security issues seems necessary for this document. On the other hand, the Document Shepherd Write-up for this document says The WG was not very energetic on this document. The document describes possible applications of CGAs and DHCP interaction and when the WG was asked whether there was enough interest to work on solutions, the reply was silence. As such, the consensus is based on most of the WG being indifferent. So maybe this document is only intended as a sketch of possible issues that can be explored later in a more in-depth document if someone is interested in doing so. If that's the case, maybe it's OK to not fully analyze all the security implications. However, in that case, I think the Security Considerations section should state clearly that this document does not contain a complete security analysis and any further work in this area should include such an analysis. Nobody should implement the techniques described in this document without conducting that more thorough analysis. I noticed a few typos. On page 6, the word certificated should be certified. Three sentences later, depend on policies should be depending on policies. And the draft names in the Change Log say dhacpv6 instead of dhcpv6. Thanks, Steve ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
secdir review of draft-ietf-ippm-spatial-composition-15.txt
I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document gives guidance on composing path metrics from sub-path metrics within the IP Performance Metrics framework. I am not an expert on IPPM but after some analysis I have concluded that the security considerations in this draft are adequate. They raise all the relevant security issues that I could come up with and provide guidance for how those issues can be addressed. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: secdir review of draft-ietf-netconf-partial-lock-09.txt
Tom, Thanks for responding to my comments. Allow me to respond. You wrote: As a participant in netconf, I see authorization as one of those topics which the Working Group sees as necessary but cannot be tackled just yet. As RFC4741 says, This document does not specify an authorization scheme, as such a scheme should be tied to a meta-data model or a data model. and as yet, there is no data model; hence, no authorization, not yet, nor, IMHO, for some time to come. This is just the sort of background information that a WG participant would know but that a secdir reviewer would not. Please allow me to ask a clarifying question. You say that there is no authorization yet. I think that could mean several things: 1) Existing NETCONF implementations implement authorization, ensuring that each user gets an appropriate and perhaps different level of access to the database. However, there are no standards for the manner in which authorization is performed or configured. 2) Existing NETCONF implementations require authentication but generally just give complete read-write access to the database to all authenticated users. 3) Existing NETCONF implementations do not require authentication. Anyone with network access has complete, unfettered access to the database and can modify it at will. Could you tell me which of these meanings is most accurate? Of course, it could be a mix of these but I'd like to get your real-world assessment of the state of the NETCONF world. If the answer is 3), we have a serious problem! If the answer is 1) or 2), that's acceptable in my view. Now on to the language in the draft. My comment was relating to this quote from the Security Considerations: Only an authenticated and authorized user can request a partial lock. I'm afraid that this statement is not justified if there is no normative text requiring implementations to comply. I suggest that normative text be added to at least require authentication. With such text, the statement above could be justified. Requiring that levels of authorization be implemented is less important in this application. And standardizing the manner in which authorization is performed or configured (which I think is your concern with respect to the lack of a data model) is really not important at all unless NETCONF customers or vendors decide that it is. Standardizing an authorization policy format is a tremendously challenging task for any protocol and often not necessary. I hope that this helps you address my comments in a reasonable and achievable manner. The intent of secdir comments is not to impose unreasonable requirements. It is to point out issues that might not be evident to someone who is not a security expert. Thanks, Steve -Original Message- From: Tom.Petch [mailto:sisyp...@dial.pipex.com] Sent: Thursday, August 13, 2009 4:00 AM To: Stephen Hanna; sec...@ietf.org; ietf@ietf.org; draft-ietf-netconf-partial-l...@tools.ietf.org Subject: Re: secdir review of draft-ietf-netconf-partial-lock-09.txt - Original Message - From: Stephen Hanna sha...@juniper.net To: i...@ietf.org; sec...@ietf.org; ietf@ietf.org; draft-ietf-netconf-partial-l...@tools.ietf.org Sent: Monday, August 10, 2009 4:28 PM I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document defines optional partial-lock and partial-unlock operations to be added to the NETCONF protocol. These operations are used to lock only part of a configuration datastore, allowing multiple management sessions to modify the configuration of a device at a single time. The Security Considerations section of the document highlights the risk that a malicious party might employ partial locks to impede access to a device's configuration. Therefore, it states Only an authenticated and authorized user can request a partial lock. Unfortunately, I cannot find any normative text (MUST) that supports this statement. The NETCONF spec (RFC 4741) says NETCONF connections must be authenticated but this is not clearly normative. Perhaps a NETCONF expert can point to some normative text requiring authentication and authorization for any party requesting a partial lock. If not, I suggest that such normative text be added to the partial-lock specification. As a participant in netconf, I see authorization as one of those topics which the Working Group sees as necessary but cannot be tackled just yet. As RFC4741 says, This document does not specify an authorization scheme, as such a scheme should be tied to a meta-data model or a data model. and as yet, there is no data model; hence, no authorization, not yet
RE: secdir review of draft-ietf-netconf-partial-lock-09.txt
Thanks to Dan and Bert for answering my question. If most NETCONF implementations authenticate users and implement some form of authorization scheme, there should be no problem with including text in draft-ietf-netconf-partial-lock-09.txt that says NETCONF servers that implement partial locks MUST ensure that only an authenticated and authorized user can request a partial lock. Even a server that implements authentication but does not implement fine-grained authorization would meet this requirement. It would just be saying that all authenticated users are fully authorized to perform any operation on the server. Are there any concerns with this proposal? If so, please explain. Thanks, Steve -Original Message- From: Bert (IETF) Wijnen [mailto:berti...@bwijnen.net] Sent: Thursday, August 13, 2009 7:35 AM To: Stephen Hanna Cc: Tom.Petch; sec...@ietf.org; ietf@ietf.org; draft-ietf-netconf-partial-l...@tools.ietf.org Subject: Re: secdir review of draft-ietf-netconf-partial-lock-09.txt Stephen, I think it is your first bullet point. We have not standardize it yet. And so it is implementation dependent as to what authorization is used. Bert Stephen Hanna wrote: Tom, Thanks for responding to my comments. Allow me to respond. You wrote: As a participant in netconf, I see authorization as one of those topics which the Working Group sees as necessary but cannot be tackled just yet. As RFC4741 says, This document does not specify an authorization scheme, as such a scheme should be tied to a meta-data model or a data model. and as yet, there is no data model; hence, no authorization, not yet, nor, IMHO, for some time to come. This is just the sort of background information that a WG participant would know but that a secdir reviewer would not. Please allow me to ask a clarifying question. You say that there is no authorization yet. I think that could mean several things: 1) Existing NETCONF implementations implement authorization, ensuring that each user gets an appropriate and perhaps different level of access to the database. However, there are no standards for the manner in which authorization is performed or configured. 2) Existing NETCONF implementations require authentication but generally just give complete read-write access to the database to all authenticated users. 3) Existing NETCONF implementations do not require authentication. Anyone with network access has complete, unfettered access to the database and can modify it at will. Could you tell me which of these meanings is most accurate? Of course, it could be a mix of these but I'd like to get your real-world assessment of the state of the NETCONF world. If the answer is 3), we have a serious problem! If the answer is 1) or 2), that's acceptable in my view. Now on to the language in the draft. My comment was relating to this quote from the Security Considerations: Only an authenticated and authorized user can request a partial lock. I'm afraid that this statement is not justified if there is no normative text requiring implementations to comply. I suggest that normative text be added to at least require authentication. With such text, the statement above could be justified. Requiring that levels of authorization be implemented is less important in this application. And standardizing the manner in which authorization is performed or configured (which I think is your concern with respect to the lack of a data model) is really not important at all unless NETCONF customers or vendors decide that it is. Standardizing an authorization policy format is a tremendously challenging task for any protocol and often not necessary. I hope that this helps you address my comments in a reasonable and achievable manner. The intent of secdir comments is not to impose unreasonable requirements. It is to point out issues that might not be evident to someone who is not a security expert. Thanks, Steve -Original Message- From: Tom.Petch [mailto:sisyp...@dial.pipex.com] Sent: Thursday, August 13, 2009 4:00 AM To: Stephen Hanna; sec...@ietf.org; ietf@ietf.org; draft-ietf-netconf-partial-l...@tools.ietf.org Subject: Re: secdir review of draft-ietf-netconf-partial-lock-09.txt - Original Message - From: Stephen Hanna sha...@juniper.net To: i...@ietf.org; sec...@ietf.org; ietf@ietf.org; draft-ietf-netconf-partial-l...@tools.ietf.org Sent: Monday, August 10, 2009 4:28 PM I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like
secdir review of draft-ietf-netconf-partial-lock-09.txt
I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document defines optional partial-lock and partial-unlock operations to be added to the NETCONF protocol. These operations are used to lock only part of a configuration datastore, allowing multiple management sessions to modify the configuration of a device at a single time. The Security Considerations section of the document highlights the risk that a malicious party might employ partial locks to impede access to a device's configuration. Therefore, it states Only an authenticated and authorized user can request a partial lock. Unfortunately, I cannot find any normative text (MUST) that supports this statement. The NETCONF spec (RFC 4741) says NETCONF connections must be authenticated but this is not clearly normative. Perhaps a NETCONF expert can point to some normative text requiring authentication and authorization for any party requesting a partial lock. If not, I suggest that such normative text be added to the partial-lock specification. Another security concern that I have related to the partial-lock operation is that the configuration might become inconsistent if one manager changes one part of a datastore at the same time that another manager changes another part. The resulting inconsistency could have security implications. For example, an organization might have a rule that either the firewall or the intrusion detection features must be enabled on a device. If one manager might lock intrusion detection configuration, check that the firewall is enabled, and then disable intrusion detection. Another manager might lock the firewall configuration, check that intrusion detection is enabled, and then disable the firewall. If those operations were interleaved, they could result in a violation of policy. To address this concern, I suggest that the draft contain a warning that parallel operations are tricky and should be carefully considered. Sometimes, it may be necessary to lock a portion of the datastore that will not be modified, just to ensure the datastore remains consistent and compliant with policy. Of course, a human administrator using a GUI could easily run into this same problem if the human does not have the ability to control configuration locks. The human might look at the firewall configuration to make sure that it's enabled and then switch to another section of the display to disable the intrusion detection function. If the management console only locks the datastore to execute the administrator's request to disable intrusion detection, overlapping operations from another administrator could result in a bad configuration. This problem can arise even without the partial lock operation. Probably the best that can be done here is to include language warning of this sort of problem. Warning human administrators that someone else is also editing the device should help and giving these administrators the ability to easily communicate with each other to coordinate their work would also probably help. Here are a few minor issues: * At the end of section 2.1.1.2, the comma in the last sentence is superfluous. * In section 2.1.1.3 in the sentence Manager A terminates it's session, the apostrophe should be removed. * In section 2.4.1, I think that the sentence that begins with If someone later creates a new interface would be clearer if the second comma was changed to so. * Later in section 2.4.1, the sentence that begins with A NETCONF server MUST should instead start with A NETCONF server that supports partial locks MUST. I think that paragraph should end with all of the overlapping locks are released not all of the locks are released. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
secdir review of draft-peterson-rai-rfc3427bis-02.txt
I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document replaces RFC 3427, refining the SIP change process. Although I have some familiarity with SIP, my knowledge of this area is minimal. I have not participated in any of the RAI WGs or in the SIP change process. My comments should therefore mainly be taken as those of an IETF common man and a security expert. I have very few security concerns related to this document. As with RFC 3427, this document continues to require all new SIP headers and event packages (the only extensions that can be registered without going through an IETF WG) to be reviewed by a Designated Expert using guidelines that include strict security requirements. My only security concern with this process is that a Designated Expert might not have much or any security expertise. A truly dedicated reviewer without such expertise would seek specialized review for security issues but many reviewers are overworked or not able to obtain security help. This problem could be solved by requiring all SIP extensions to become RFCs, therefore ensuring that they get broad review, including secdir reviews. RFC 3427 required this. This draft proposes to remove the requirement for RFC publication for SIP headers, allowing IANA registration of SIP headers that receive Designated Expert review but are not published as RFCs. I suggest that this change not be made since it will reduce the security review of these extensions. Another reason to not allow IANA registration of SIP headers without RFC publication is that there may not be a permanent and clear definition of these headers. If a header is only documented on a vendor web site, that documentation can disappear at any time. Other changes that were made to the SIP header registration process include a large reduction in the number of guidelines for expert reviewers. The requirements dropped include these: applicability to SIP, lack of overlap with current or planned SIP extensions, clear documents, and an applicability statement when the extension is not suitable for use on the Internet. Removing those guidelines seems unwise to me. I have divided the rest of my comments into substantive and non-substantive comments. First, the substantive ones. * Does the term consensus in the first sentence of the third paragraph of section 3 refer to WG consensus or IETF consensus? I believe that it refers to WG consensus but this should be clarified. * The last sentence of the fifth paragraph in section 3 says that the DISPATCH working group may approve proposals for extensions if the requirements are judged to be appropriate to SIP, but are not sufficiently general for standards track activity. I think that these proposals would then proceed as individual submissions. If that's right, I suggest that this be mentioned in this sentence. * The first paragraph of section 4.1 says that Normal event packages can be created and registered by the publication of any Working Group RFC (Informational, Standards Track, Experimental), provided that the RFC is a chartered working group item. However, the next paragraph describes how individual submissions for event packages may be published. This seems to be a contradiction. Maybe the sentence that I just quoted is not intended to exhaustively describe all the ways that event packages can be created. If that's the case, the sentence should be clarified. * Paragraph four of section 4.1 says that the procedure for registering event packages developed outside the scope of an IETF working group is RFC Required. However, the process described in the following paragraphs would better be described as RFC Required with Designated Expert Review. * As the first paragraph in the Security Considerations section says, feature interactions can have significant security implications. However, the text should go one step beyond to require that all RFCs that modify or extend SIP must consider the security implications of feature interactions. * The fifth paragraph of section 7 says that For event template packages, registrations must follow the RFC5226 processes for Standards Action. Actually, the earlier part of this document included an additional requirement that such specifications must be developed by an IETF Working Group. Probably that should be documented here. * The fifth paragraph of section 7 also states that IETF Review is the process used for ordinary event packages. That is not consistent with section 4.1, which states that the process for these is RFC Required (with Designated Expert review). I think that section 4.1 is correct and the text in section 7
secdir review of draft-ietf-krb-wg-naming-04.txt
I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. Document editors should treat these comments just like any other comments. This document defines conventions for well-known Kerberos principal names and well-known Kerberos realm names. While the document seems to be pretty thorough, the Security Considerations section is too brief. This is especially true for a document whose main purpose is to modify a criticial security protocol such as Kerberos. The Security Considerations section could provide an example of how unintended access could be granted if an authentication with an unsupported well-known name is allowed to succeed. More important, it should explain why it is permissible for the TGS to allow an authentication to succeed even if the client and/or server principal name is an unsupported well-known name. The reasoning for allowing this is not clear to me but perhaps it is that the TGS can assume that the AS must have supported the client name or it would have failed the authentication. I'm not sure how this helps to address the case where the server name is an unsupported well-known name. I would like to see that explained, preferably in the document. I also noticed a few typos: At the end of section 1, remedy these should be remedy these issues or something similar. Otherwise, it's not clear what is to be remedied. In the last paragraph of section 3.1, the first word is in the phrase is a well-known principal name is used should be if. Similarly, in the second paragraph of section 3.2, the first word is should be if in the phrase is a well-known realm name is used. Other than these issues, the document seems to be OK. Thanks, Steve ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
secdir review of draft-ietf-l2vpn-vpls-mcast-reqts-05.txt
I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other late last call comments. This document describes requirements for multicast support in Virtual Private LAN Services (VPLS). This is not an area of particular expertise for me but I have considerable experience with multicast and security so I think this analysis is at least worthy of consideration. *Overall Clarity and Quality* The document is fairly clear in its description of requirements. The reader must consult a large number of referenced documents but this is not unusual in modern IETF specifications. I'm pleased to see this relative clarity since vagueness can easily lead to misunderstandings, interoperability problems, and security holes. *Security Analysis* Unfortunately, the document does not contain a systematic security analysis of the problem. The Security Considerations section consists of two brief paragraphs. These paragraphs refer to other sections in the document where security requirements are listed and to RFC 4665, which also lists security requirements. However, I could not find any methodical threat analysis listing the possible threats relevant to the system and stating which ones are protected against and which are not. Without a thorough threat analysis, I have little confidence that the authors have thought carefully about the possible threats to the system. I would expect this to lead to large gaps in the security requirements and this seems to be borne out in practice. For example, there is no discussion of threats due to compromise of components within the service provider network. Even more troublesome, I think that a single node at a customer site (presumably untrusted) can mount dangerous attacks. For example, a node that joins many multicast groups can cause a large amount of state to be maintained in the L2VPN. While section 6.6 of the document says that a multicast VPLS solution SHOULD have mechanisms to protect a SP network from [...] high volumes of valid/invalid customer control packets, it is not clear how this protection will be provided. If it takes the form of limiting the number of control packets, one node can exhaust the customer's quota and effectively shut down the ability for other nodes at that site to join multicast groups. In fact, later in that section it is stated that policing [to limit unwanted data traffic] MAY be configurable to the sum of unicast, multicast, broadcast and unknown unicast traffic. If this was implemented, one node at a customer site could bring down all incoming multicast AND unicast traffic to the site by joining a few high-traffic multicast groups. I expect that this is not what the authors had in mind but it's permissible according to the requirements contained in this document. Section 6.6 of the document contains most of the security requirements in the document. However, many of these are SHOULDs or even MAYs. At least, the document should describe the negative effects of not meeting these weak requirements. What threats are not protected against? I suspect that when this is done, the Working Group may reconsider the weakness of these requirements. Although I recognize that unicast traffic to unknown destinations is out of scope for this document, it is mentioned. I am concerned that security issues related to such traffic may be falling through the cracks and not be covered by any specification. If this traffic can cause flooding and then state maintenance in the L2VPN, there may be threats where a malicious node sends such traffic to a variety of unknown destinations to cause excess traffic and state in the L2VPN. *Conclusion* I recommend that a thorough security analysis be conducted for this document and included in the document. All threats identified in this analysis should be addressed by adding a requirement pertaining to them or by explicitly stating that the threat will not be addressed and why and what the ramifications are. Until this is done, this document should not progress. To do otherwise might cause substantial damage to the security of customer networks that employ L2VPN services. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
secdir review of draft-ietf-dnsop-reflectors-are-evil-04.txt
I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. DNS is not my area of expertise but the document clearly explains the nature of the problem to be solved (DOS attacks that employ DNS servers as amplifiers) and the recommendations for solving the problem (employing ingress filtering to prevent IP address spoofing and changing nameservers to provide recursive name lookup service only to the intended clients). I have no issue with the main content of the document. It does seem like a worthwhile recommendation. However, I have a few comments. The Introduction seems a bit defensive in stating that the DOS attacks are not due to any flaw in the design of DNS or its implementations. While the blame for the attacks lies with the attackers, some aspects of nameserver configuration, behavior, and even protocol design make the systems vulnerable to these attacks. I suggest that the defensive language be removed. Although I agree that ingress filtering is a good solution to this problem and provides many other benefits since it addresses many different attacks that involve spoofed IP addresses, the document states repeatedly that ingress filtering is the only solution to the problem. Ingress filtering may be the best solution but it is NOT the only solution, as evidenced by the other measures described in the document. None of these measures (including increased use of ingress filtering) will provide complete and absolute protection against DOS attacks that use nameservers as attack amplifiers. Employing all of the measures as appropriate while emphasizing the huge benefits of ingress filtering seems like the best approach. So I suggest that the wording in the document be toned down to take a more balanced approach to the problem. Finally, I wonder whether other more fundamental techniques for addressing the problem have been explored. For instance, if DNS clients were required to perform a simple handshake before a DNS server sent a long response, fake requests would provide little amplification. For example, requests that elicit long responses could prompt a shift to TCP. Of course, this would have other unpleasant side effects such as slowing down the processing of DNS requests with long responses and troubles getting DNS requests through firewalls. I'm not suggesting that this approach be discussed in this document, simply that it be considered (which probably has already been done). Thanks, Steve ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
secdir review of draft-ietf-dhc-server-override-04.txt
I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. The analysis of threats and countermeasures in the Security Considerations section of this document is OK. Overall, I do not have any concerns about the approval of this document after the few issues listed here are corrected. Making these corrections should not be difficult. The Security Considerations section of the document has a few issues. First, the damage that a rogue DHCP relay could cause also includes changing DHCP options in DHCPACK messages and extending leases when they should not be extended. Second, the current text implies that either DHCP authentication or DHCP Relay Agent option authentication can be deployed to provide adequate protection against the threats described. Actually, this is not accurate. DHCP Relay Agent option authentication alone will not suffice unless protection is in place against the introduction of rogue DHCP relays. Without DHCP authentication, a rogue relay could simply change the Server Identifier in the DHCPOFFER without detection. Third, this draft does not add any new vulnerabilities that were not already present, except in the case where DHCP authentication is already in place and DHCP clients require its use. This should be noted. Fourth, this draft should recommend that either DHCP authentication SHOULD be deployed or protection be provided against the insertion of rogue DHCP relays and servers. Such protection continues to be essential in protecting clients from misconfiguration. A discussion of the security benefits provided by this option (if any) would also be useful. Apparently, this option extends the benefits of the DHCP Relay Agent Info option as described in section 4.0 of 3046 to cases where the DHCP client sends unicast packets (like the RENEWING state). I'm not sure that any of these benefits actually apply in that circumstance but it would be good to describe any security benefits provided. Here are a few non-security comments: On the last line of page 5, I think the phrase all DHCP packets all servers should be all DHCP packets to all servers. The document should reference essential docs earlier, no later than section 3. For example, RFC 3046 is not actually referenced at all, although clearly section 5 intends to do so. This document should reference DHCPv6, since it is referred to. The references should be divided into normative and informative. The reference in section 5 should be to [6] not [3]. BTW, I am on vacation this week with limited Internet access so I may be late in responding to email. Sorry about that. Thanks, Steve Hanna ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: [Nea] WG Review: Network Endpoint Assessment (nea)
Ted Hardie wrote: For the charter discussions, I want to know whether it will be an aim of the working group to standardize: * a way of carrying this information * the structure of this information (but not its content) * a standard representation of the content, so that access to the vendor database is no longer required I believe that we'll need to define all three of these. There may be times when access to an external database would be useful (if you want to know exactly which viruses are covered by which AV defs version, for example) but such access should not be required to use the standard attributes. Thanks, Steve ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: [Nea] WG Review: Network Endpoint Assessment (nea)
Sam Hartman wrote: One of the things coming out of the most recent BOF was a strong desire for PA-level interoperability. That can be accomplished through standardized attributes or vendor-specific attributes that are sufficiently well documented (and not subject to patents) that third parties can implement collectors or analysis tools that interoperate with the vendor tools for the vendor attributes. Will we be able to meet these interoperability goals? Why or why not? Yes, we can. If we define a small set of standardized attributes (OS and app version, AV status, etc.) and make them mandatory to implement, then we will have interoperability with respect to those attributes. We should allow the definition of attributes that go beyond this minimal standard mandatory to implement (MTI) set but the MTI set will provide a baseline of information available for all endpoints that implement NEA. Thanks, Steve ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: [Nea] WG Review: Network Endpoint Assessment (nea)
Vidya Narayanan wrote: I am very apprehensive of achieving any meaningful PA-level interoperability. I am not sure what minimum set of PA attributes will be standardized, but, whatever that set is, I doubt will be sufficient to provide any acceptable level of security, even for the endpoints. This is not surprising, since you have said that you don't see any security value to NEA. Even assuming ongoing standardization of vendor specific attributes, it is not totally realistic to assume that all applications will support the appropriate attributes. The rate of standardization is also very likely to be much slower than the rate of the growth in the number of attributes needed for any continued meaningful protection. NEA is not based on applications supporting attributes. Attributes are supported by Posture Collectors and Posture Validators, specialized NEA components. An AV Posture Collector will handle attributes pertaining to AV, perhaps by interfacing with an existing AV application. Still, I agree that a given endpoint will typically only support a small subset of the universe of possible attributes. Not a problem. As long as the endpoint supports enough attributes that the Posture Broker can evaluate its compliance with the posture policy, that's enough. Thanks, Steve -Original Message- From: Narayanan, Vidya [mailto:[EMAIL PROTECTED] Sent: Monday, October 16, 2006 5:06 PM To: Sam Hartman; Frank Yeh Jr Cc: Hardie, Ted; [EMAIL PROTECTED]; ietf@ietf.org Subject: RE: [Nea] WG Review: Network Endpoint Assessment (nea) Sam, -Original Message- From: Sam Hartman [mailto:[EMAIL PROTECTED] Sent: Friday, October 13, 2006 12:43 PM To: Frank Yeh Jr Cc: Hardie, Ted; [EMAIL PROTECTED]; ietf@ietf.org Subject: Re: [Nea] WG Review: Network Endpoint Assessment (nea) Frank == Frank Yeh [EMAIL PROTECTED] writes: Frank Standardized VS vendor-specific attributes is not something that needs to be Frank solved today. Solutions can start with vendor-specific and migrate toward a Frank standard, if one develops, without changing the protocol. The specification Frank should not preclude the addition of standardized attributes. IE the Frank specification is like an alphabet, attributes are like vocabulary. You can add Frank new words without changing the letters. One of the things coming out of the most recent BOF was a strong desire for PA-level interoperability. That can be accomplished through standardized attributes or vendor-specific attributes that are sufficiently well documented (and not subject to patents) that third parties can implement collectors or analysis tools that interoperate with the vendor tools for the vendor attributes. Will we be able to meet these interoperability goals? Why or why not? I am very apprehensive of achieving any meaningful PA-level interoperability. I am not sure what minimum set of PA attributes will be standardized, but, whatever that set is, I doubt will be sufficient to provide any acceptable level of security, even for the endpoints. Even assuming ongoing standardization of vendor specific attributes, it is not totally realistic to assume that all applications will support the appropriate attributes. The rate of standardization is also very likely to be much slower than the rate of the growth in the number of attributes needed for any continued meaningful protection. Regards, Vidya ___ Nea mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/nea ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: WG Review: Network Endpoint Assessment (nea)
Ted, As I understand your concerns expressed below, you are concerned that standardizing attributes for NEA would be redundant and pointless: redundant because vendor-specific attributes will cover the same information in more detail and pointless because remediation will not be possible given the limited information available through the standardized attributes. Is that right? If so, maybe it would help to explain why we want to have standardized attributes. The goal is to ensure that any NEA endpoint and server can interoperate in a meaningful manner without making the assumption that endpoint and server have the same vendor plug-ins installed. For this to be true, we must ensure that every NEA endpoint provides a basic set of information to the NEA server. That basic set of information will be the standardized attributes. If the endpoint and server both understand vendor-specific attributes that provide more information, that's great. But we want to ensure a base level of interoperability. Yes, remediation may be difficult using only the information in the standardized attributes. But a captive portal technique can be used to provide information to the endpoint user about how to remediate. Thanks, Steve Ted Hardie wrote: I have a very basic fear that this working group is getting chartered with a bunch of aims added by people who will not take on the task of doing the work. After private discussion with folks involved, my sense is that the very core of this work is a perceived need to be able to pass opaque strings between a host and the network prior to the host attaching. Those opaque strings are, essentially, the vendor-specific strings currently associated with posture assessment. The standard protocol carrying these strings would connect on the network side to a system that has plug-ins which understand the vendor-specific strings. With a charter that clarified that this was intended to assist the end systems with vulnerabilities prior to attachment because the network they are attaching to might be filled with danger, I think this work would get done reasonably quickly. (As a control mechanism to protect the network, I agree with the point made clearly by others that this is not appropriate). I am less sure of the task of standardizing attributes. I am not sure that the number of attributes which can be standardized will ever be high enough to be truly useful, and I am pretty sure that all of these will be already covered by vendor-specific attributes. Since there must be an assessor in place on the client for those few standardized attributes to be assessed and that assessor will likely already have these covered by vendor-specific attributes, in other words, we seem to be standardizing redundancy. On the network attachment side, it is possible, of course, that an offer of remediation could be made based on just the standard attributes, but it seems far more likely that it would be a two step process (assess standard attributes, then pass vendor-specific attributes to vendor plug-in). Again, if the vendor's attributes cover the standard attributes, then this is largely redundant and may add measurable latency; it seems far more likely that step one would simply be skipped if there were a vendor-specific string and an available plug-in. Since there has to be an assessor, the first seems very likely to me. If you don't have a vendor's plug-in, then I suppose there is some chance that you will trust and act based on the standard attributes, but the chance of getting the right remediation seems pretty slight in those circumstances. Especially when many vulnerabilities are a combination of conditions, (Browser version Foo on OS patch level Bar) that you could remediate by upgrading either one, checking for and acting on the attributes which could be standardized seems of very, very limited utility. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: [Nea] Re: WG Review: Network Endpoint Assessment (nea)
Vidya, Thanks for your response. I think we may be getting closer to understanding each other's perspectives. That's a good thing. Let me respond to your comments inline below. I hope you won't mind if I clip a bit since this thread is starting to get long. Vidya Narayanan wrote: A. Any network is exposed to threats from lying endpoints, compromised endpoints and unknown vulnerabilities even on NEA-compliant endpoints. B. A network needs to be protected against such generic threats (as listed in A). Agreed. There are plenty of other threats but that's enough for now. I am rather confused by this attempt to make NEA fit into some kind of a network protection mechanism. I keep hearing that NEA is *one* of a suite of protocols that may be used for protecting networks. Let's dig a bit deeper into what a network may employ as protection mechanisms in order to protect against all kinds of general threats. i) Access control mechanisms such as authentication and authorization (to ensure only valid endpoints are allowed on the network) ii) Ingress address filtering to prevent packets with topologically incorrect IP addresses from being injected into the network iii) VPNs to provide remote access to clients iv) Firewalls to provide advanced filtering mechanisms v) IDS/IPS to detect and prevent intrusions vi) Application level filtering where applicable (e.g., detecting and discarding email spam) A combination of the above (or the like) needs to be used to address the general threats mentioned above (in B, for e.g.). Given that, what does NEA bring to the network that isn't already provided by such mechanisms that need to be employed anyway? It is not like we can stop using some of these mechanisms if NEA is present, since the threats that NEA may protect against (from the network perspective) are a small subset of the general threats that a network operator must consider. And, when the general threats are addressed, any subset of those threats are also addressed. NEA is another network security tool. Like the others, it has some special advantages but does not remove the need for the others. What does NEA provide that isn't provided by the others? NEA can 1) identify unhealthy endpoints (vulnerable or infected) 2) quarantine unhealthy endpoints before they can infect others or become infected (optionally) 3) repair unhealthy endpoints (optionally) Yes, NEA cannot provide all these functions itself. NEA provides a framework for passing messages about endpoint health. Other security products use that framework to collect, send, and validate specific posture attributes and then to send remediation instructions and/or quarantine unhealthy endpoints. The effectiveness of NEA is tied to the type of endpoint (i.e., truthful, compliant endpoints with known vulnerabilities). A network, OTOH, needs mechanisms that protect against all kinds of endpoints. I fail to understand why a particular category of endpoints that NEA addresses is not viewed as a subset of the general category of all endpoints. With the aid of technology for detecting lying endpoints, NEA can also handle that class of endpoints. But I agree that NEA will probably never apply to every endpoint on the network. For endpoints that support NEA, the network operator can provide better security. For endpoints that don't support NEA, it will be status quo. Steve Hanna wrote: In the context of an overall security program and when combined with other security technologies, NEA can help protect networks. Let me list the ways. First, NEA can help improve the security of cooperating, truthful endpoints. How is this network protection? As you state above, it is about improving the security of co-operating, truthful *endpoints*. Network security is improved because fewer cooperating, truthful endpoints turn into uncooperative, infected endpoints that then flood the network with attacks. Second, NEA can be used with technology for detecting lying endpoints. This prevents compromised systems from lying to gain access to the network, thus providing a huge improvement in network security. Once again, given that a network operator must really protect against many generic threats, what kind of improvement is NEA bringing to the security of the network? See my comments above. Third, endpoints that don't initially participate in NEA protocols can be quarantined for further examination with an external vulnerability scanner or a dynamically downloaded NEA client. Again, this is not part of the proposed NEA WG charter but it is another example of ways that NEA can be used with other security technologies to improve network security. I'm confused by the above - what is the role of NEA here? I'm pointing out that endpoints that don't initially participate in NEA protocols can be quarantined and directed to a web page where they can run a dynamically downloaded
Re: WG Review: Network Endpoint Assessment (nea)
I have seen a lot of discussion about whether NEA provides network protection. In fact, it has been suggested that the charter be revised to say NEA must not be considered a protection mechanism for networks. I don't agree. Let's start by examining this concept of network protection. It's an awfully broad concept. No single security technology can provide total protection for a network against all attacks. Instead, a careful threat analysis must be done and layered countermeasures put in place: firewalls, malware scanning, intrusion detection and prevention, strong authentication and authorization, strong encryption for data at rest and in transit, user education, etc. In the context of an overall security program and when combined with other security technologies, NEA can help protect networks. Let me list the ways. First, NEA can help improve the security of cooperating, truthful endpoints. When a cooperating, truthful endpoint connects to the network, its health can be checked and any problems fixed before it can come under attack. This helps protect networks by keeping endpoints healthy so that fewer endpoints become infected and potentially impact the network through port scanning and other misbehavior. The protection provided by NEA alone is not absolute. Healthy endpoints can be vulnerable to a zero day attack. And NEA on its own provides no protection against lying endpoints and no protection against hosts that don't participate in NEA protocols. But it's a lot better than today's situation where some endpoints are completely unprotected with patches or anti-virus software. Second, NEA can be used with technology for detecting lying endpoints. This prevents compromised systems from lying to gain access to the network, thus providing a huge improvement in network security. I recognize that technology for detecting lying endpoints is out of scope for the NEA effort but we shouldn't pretend that it doesn't exist. Without NEA or similar protocols, it will be hard to integrate lying endpoint detection systems into network access control. That's why the NEA BOF in Montreal agreed to include language in the charter saying that the protocols developed by the NEA WG must be designed to accommodate emerging technologies for identifying and dealing with lying endpoints. Third, endpoints that don't initially participate in NEA protocols can be quarantined for further examination with an external vulnerability scanner or a dynamically downloaded NEA client. Again, this is not part of the proposed NEA WG charter but it is another example of ways that NEA can be used with other security technologies to improve network security. To summarize, the NEA protocols will increase network security on their own. When combined with other technologies, the increase in network security is much greater. But either way it is not accurate to say that NEA is not a protection mechanism for networks. Thanks, Steve ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
